Enable CONFIG_SYS_PCI_64BIT to allow 64bit access to PCI space.
Signed-off-by: NKunihiko Hayashi <hayashi.kunihiko@socionext.com>

Add PCIe driver for UniPhier SoCs. This PCIe controller is based on
Synopsys DesignWare Core IP.

This version doesn't apply common DW functions because supported
controller doesn't have unroll version of iATU.
Signed-off-by: NKunihiko Hayashi <hayashi.kunihiko@socionext.com>

Add PCIe PHY driver support for Pro5, LD20 and PXs3 SoCs.
Signed-off-by: NKunihiko Hayashi <hayashi.kunihiko@socionext.com>

Add reset control for PCIe controller on each SoC.
Signed-off-by: NKunihiko Hayashi <hayashi.kunihiko@socionext.com>

Add clock control for PCIe controller on each SoC.
Signed-off-by: NKunihiko Hayashi <hayashi.kunihiko@socionext.com>

I'm no longer work in Intel, change Intel SoCFPGA co-maintainer to
Tien Fong Chee.
Signed-off-by: NLey Foon Tan <lftan.linux@gmail.com>
Acked-by: NMarek Vasut <marex@denx.de>

According to arch/arm/lib/crt0_64.S, the BSS section is "UNAVAILABLE"
and uninitialized before relocation. Also, it overlaps with the
appended DTB before relocation, so writing data into a variable
in the BSS section might corrupt the appended DTB.

Unfortunately, pinctrl-apq8016.c and pinctrl-apq8096.c do place the
"pin_name" variable in the BSS section (since it's uninitialized).
It's also used before relocation, when setting up the pinctrl for
the serial driver.

On DB410c this causes "GPIO_5" to be written into some part of an
appended DTB, e.g.:

80111820: edfe0dd0 9f100000 38000000 c00e0000    ...........8....
80111830: 28000000 11000000 10000000 00000000    ...(............
80111840: 4f495047 8800355f 00000000 00000000    GPIO_5..........
80111850: 00000000 00000000 01000000 00000000    ................
80111860: 03000000 04000000 00000000 02000000    ................
80111870: 03000000 04000000 0f000000 02000000    ................
80111880: 03000000 2d000000 1b000000 6c617551    .......-....Qual
80111890: 6d6d6f63 63655420 6c6f6e68 6569676f    comm Technologie

Depending on the part of the DTB that is corrupted this might not
cause any problems, but it can also result in strange reboots
without any serial output.

Fortunately, in practice this does not cause issues on DB410c yet
because board_fdt_blob_setup() in dragonboard410c.c currently
overrides the appended DTB with the one passed by the previous
bootloader (LK) (which does not get corrupted).

DB820c does not have board_fdt_blob_setup() so I would expect it to
be affected by this problem. Perhaps everyone was just fortunate to
not compile an U-Boot configuration where the pin_name corrupts an
important part of the DTB.

Make sure "pin_name" is explicitly placed in the .data section
instead of .bss to fix this.

Cc: Ramon Fried <rfried.dev@gmail.com>
Signed-off-by: NStephan Gerhold <stephan@gerhold.net>
Reviewed-by: NRamon Fried <rfried.dev@gmail.com>

The sysinfo_get_str() implementation checks whether the sysinfo was even
detected. In U-Boot proper, sysinfo_detect() is not called anywhere but
on one specific board. Call sysinfo_detect() before sysinfo_get_str() to
make sure the sysinfo is detected and sysinfo_get_str() returns valid
value instead of -EPERM.
Signed-off-by: NMarek Vasut <marek.vasut+renesas@gmail.com>
Cc: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Replace uclass_first_device_err(UCLASS_SYSINFO, &dev) with sysinfo_get(&dev).
The board_info code may use sysinfo to print board information, so use the
sysinfo functions consistently. The sysinfo_get() is internally implemented
as return uclass_first_device_err(UCLASS_SYSINFO, &dev) anyway, so there is
no functional change.
Signed-off-by: NMarek Vasut <marek.vasut+renesas@gmail.com>
Cc: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Linux kernel binding is using atmel,24c01 compatible string. On the
other hand there is atmel,24c01a which is not listed in the kernel.
Add compatible string without "a" suffix to be compatible with Linux
kernel binding.
Signed-off-by: NMarek Vasut <marek.vasut+renesas@gmail.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: NHeiko Schocher <hs@denx.de>

Simplify the code a bit by using dev_read_addr_ptr() instead of
dev_read_addr(). This avoids having to cast explicitly to the
struct nomadik_mtu_regs.
Signed-off-by: NStephan Gerhold <stephan@gerhold.net>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>

Nomadik GPIO is a fairly simple GPIO module used in the ST-Ericsson
Ux500 SoCs (and some older Nomadik SoCs). It uses registers where
each GPIO is represented as a single bit, plus "set" and "clear"
registers that allow updating the state without having to read the
existing state.

The driver implements support for it for use together with DM_GPIO
and the existing ste-dbx5x0.dtsi device tree.

Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: NStephan Gerhold <stephan@gerhold.net>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>

The original U-Boot port for the ST-Ericsson U8500 SoC was dropped
in commit 68282f55 ("arm: Remove unused ST-Ericsson u8500 arch").
Most of the drivers related to the old port were removed, but the
db8500_gpio.c driver was forgotten for some reason. There is no way
to select it and it does not compile anymore because of missing
headers, so let's just remove it.

The new port for U8500 introduced in commit 689088f9
("arm: Add support for ST-Ericsson U8500 SoC") fully embraces the
new Driver Model and device trees where possible, so this is
preparation to add a new, simplified GPIO driver based on DM_GPIO.
Signed-off-by: NStephan Gerhold <stephan@gerhold.net>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>

This information will be maintained in the device tree instead.
Signed-off-by: NAnders Dellien <anders.dellien@arm.com>

Pull request for efi-2021-10-rc1

Documentation

* fix typo in signature.txt

UEFI

* provide file attributes in EFI_FILE_PROTOCOL.Read()
* various capsule update fixes

Fix find_boot_device() to set bootdev_root if it finds the
bootdev from BootNext. Currently it sets the bootdev_root only
when it finds bootdev from BootOrder.

Fixes: c74cd8bd ("efi_loader: capsule: add capsule_on_disk support")
Signed-off-by: NMasami Hiramatsu <masami.hiramatsu@linaro.org>
Accked-by: NIlias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

If multiple capsules are applied, the FMP drivers for the individual
capsules can expect the value of CapsuleLast to be accurate. Hence
CapsuleLast must be updated after each capsule.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

efi_set_variable() should be called with EFI_CALL(). Use
efi_set_variable_int() instead.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

* Use log category LOGC_EFI. This allows to remove 'EFI:' prefixes in
  messages.
* Rephrase some of the messages.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

When reading a directory using EFI_FILE_PROTOCOL.Read() provide file
attributes and timestamps.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

We should avoid #ifdef in C modules. Unused functions are eliminated by the
linker.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

When reading a directory in the UEFI file system we have to return file
attributes and timestamps. Copy this data to the directory entry structure.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

Fix value fields in signature nodes.
Signed-off-by: NThomas Perrot <thomas.perrot@bootlin.com>
Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

Aside from the usual fixes and updates one visible change is the
MMC update, which fixes some lingering bugs and gives a decent speed
increase on some boards (9->19 MB/s on H6, 21->43 MB/s on A64 eMMC).
I am keeping an watchful eye on bug reports here, to spot any correctness
regressions.
Another change is finally the enablement of the first USB host port on
many boards without micro-USB (data) sockets, like the Pine64 family.
That doubles the number of usable USB ports from 1 to 2 on those boards.

Some smaller fixes, 4GB DRAM support (on the H616) and a new board (ZeroPi)
conclude this first round of changes.

Compile-tested for all 157 sunxi boards, boot-tested on Pine H64,
Pine64-LTS, OrangePi Zero 2 and BananaPi M2 Berry.

Summary:
- DT update for H3/H5/H6
- Enable first USB port on boards without micro-USB
- ZeroPi board support
- 4GB DRAM support for H616 boards
- MMC fixes and speed improvement
- some fixes

At the moment the Allwinner MMC driver parses the bus-width and
non-removable DT properties itself, in the probe() routine.

There is actually a generic function provided by the MMC framework doing
this job, also it parses more generic properties like broken-cd and
advanced transfer modes.

Drop our own code and call mmc_of_parse() instead, to get all new
features for free.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Reviewed-by: NJaehoon Chung <jh80.chung@samsung.com>

To avoid the complexity of DMA operations (with chained descriptors), we
use repeated MMIO reads and writes to the SD_FIFO_REG, which allows us
to drain or fill the MMC data buffer FIFO very easily.

However those MMIO accesses are somewhat costly, so this limits our MMC
performance, to between 17 and 22 MB/s, but down to 9.5 MB/s on the H6
(partly due to the lower AHB1 frequency).

As it turns out we read the FIFO status register after *every* word we
read or write, which effectively doubles the number of MMIO accesses,
thus effectively more than halving our performance.

To avoid this overhead, we can make use of the FIFO level bits, which are
in the very same FIFO status registers.
So for a read request, we now can collect as many words as the FIFO
level originally indicated, and only then need to update the status
register.

We don't know for sure the size of the FIFO (and it seems to differ
across SoCs anyway), so writing is more fragile, which is why we still
use the old method for that. If we find a minimum FIFO size available on
all SoCs, we could use that, in a later optimisation.

This patch increases the eMMC read speed on a Pine64-LTS from about
22MB/s to 44 MB/s. SD card reads don't gain that much, but with 23 MB/s
we now reach the practical limit for 3.3V SD cards.
On the H6 we double our transfer speed, from 9.5 MB/s to 19.7 MB/s.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>

Newer SoCs have a self calibration feature, which avoids us writing hard
coded phase delay values into the controller.

Consolidate the code by avoiding unnecessary #ifdefs, and also enabling
the feature for all those newer SoCs.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>

All SoCs since the Allwinner A64 (H5, H6, R40, H616) feature the so
called "new timing mode", so enable this in Kconfig for those SoCs.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>

Among the SoCs using the "new timing mode", only the A83T needs to
explicitly switch to that mode.

By just defining the symbol for that one odd A83T bit to 0 for any other
SoCs, we can always OR that in, and save the confusing nested #ifdefs.

Clean up the also confusing new_mode setting on the way.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Reviewed-by: NJaehoon Chung <jh80.chung@samsung.com>

Most Allwinner SoCs which use the so called "new timing mode" in their
MMC controllers actually use the double-rate PLL6/PERIPH0 clock as their
parent input clock. This is interestingly enough compensated by a hidden
"by 2" post-divider in the mod clock, so the divider and actual output
rate stay the same.

Even though for the H6 and H616 (but only for them!) we use the doubled
input clock for the divider computation, we never accounted for the
implicit post-divider, so the clock was only half the speed on those SoCs.
This didn't really matter so far, as our slow MMIO routine limits the
transfer speed anyway, but we will fix this soon.

Clean up the code around that selection, to always use the normal PLL6
(PERIPH0(1x)) clock as an input. As the rate and divider are the same,
that makes no difference.
Explain the hardware differences in a comment.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>

When enabling PHYS_64BIT on 32-bit platforms, we get two warnings about
pointer casts in sunxi_mmc.c. Those are related to MMIO addresses, which
are always below 1GB on all Allwinner SoCs, so there is no problem with
anything having more than 32 bits.

Add the proper casts to make it compile cleanly.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Reviewed-by: NJaehoon Chung <jh80.chung@samsung.com>

The delay and bus-width setup are slightly different across the
Allwinner SoC generations, and we covered this so far with some
preprocessor conditionals.

Use the more readable IS_ENABLE() instead.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Reviewed-by: NJaehoon Chung <jh80.chung@samsung.com>

The H616 is our first supported Allwinner SoC which goes beyond the 4GB
address space "barrier", by having more than 32 address bits.

Lift the preliminary 3GB DRAM limit for the H616, and update the page
table setup on the way, to actually map that last GB as well.

As not all devices are actually capable of dealing with more than 32
bits (the DMA in the EMAC for instance), we also limit U-Boot's own
DRAM usage to 4GB on the way.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>

We hardcode the pinctrl setting for the MMC controllers in boards.c,
since we need them also in the SPL, where there is no DT yet.

Add the respective setting for the H616 SoC, to enable eMMC on boards
with this SoC as well.
Also to make diagnosing this problem easier, print a warning if a board
tries to setup MMC2 pins without a respective SoC setting being defined.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Reviewed-by: Jagan Teki <jagan at amarulasolutions.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec at siol.net>

ZeroPi is a new board of high performance with low cost
designed by FriendlyElec., using the Allwinner H3 SOC.

ZeroPi features
- Allwinner H3, Quad-core Cortex-A7@1.2GHz
- 256MB/512MB DDR3 RAM
- microsd slot
- 10/100/1000Mbps Ethernet
- Debug Serial Port
- DC 5V/2A power-supply
Signed-off-by: NYu-Tung Chang <mtwget@gmail.com>
Reviewed-by: NAndre Przywara <andre.przywara@arm.com>
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>

OrangePi PC2 board has DRAM with ODT, so enable it.
H5 SoC is also connected to voltage regulator. It's default value is
reasonable at reset, but might be too low when rebooting with a lower
voltage programmed. In order to avoid instability, enable driver for it
and set it to appropriate voltage.
Signed-off-by: NJernej Skrabec <jernej.skrabec@gmail.com>
Tested-by: NAndre Przywara <andre.przywara@arm.com>
[Andre: remove original ZQ value change, adjust commit message]
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>

Most clock factors and dividers in the H6 PLLs use a "+1 encoding",
which we were missing on two occasions.

This fixes the MMC clock setup on the H6, which could be slightly off due
to the wrong parent frequency:
mmc 2 set mod-clk req 52000000 parent 1176000000 n 2 m 12 rate 49000000

Also the CPU frequency (PLL1) was a tad too high before.

For PLL5 (DRAM) we already accounted for this +1, but in the DRAM code
itself, not in the bit field macro. Move this there to be aligned with
what the other SoCs and other PLLs do.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Reviewed-by: NJernej Skrabec <jernej.skrabec@gmail.com>

Recent Allwinner platforms (starting with the H3) only use the MUSB
controller for peripheral mode and use HCI for host mode. As a result,
extra steps need to be taken to properly route USB signals to one or
the other. More precisely, the following is required:
* Routing the pins to either HCI/MUSB (controlled by PHY);
* Enabling USB PHY passby in HCI mode (controlled by PMU).

The current code will enable passby for each PHY and reroute PHY0 to
MUSB, which is inconsistent and results in broken USB peripheral support.

Passby on PHY0 must only be enabled when we want to use HCI. Since
host/device mode detection is not available from the PHY code and
because U-Boot does not support changing the mode dynamically anyway,
we can just mux the controller to MUSB if it is enabled and mux it to
HCI otherwise.

This fixes USB peripheral support for platforms with PHY0 dual-route,
especially H3/H5 and V3s.
Signed-off-by: NPaul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>

Update the H3 DT files from the Linux 5.12 release.

The changes update some boards, and don't affect U-Boot, but fix Gigabit
Ethernet when this DT is passed on to the Linux kernel.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>

Update the H5 DT files from the Linux 5.12 release.

The changes don't affect U-Boot at all, but fix Gigabit Ethernet when
this DT is passed on to the Linux kernel. It also introduces DVFS.

This also updates the shared sunxi-h3-h5.dtsi, but that only adds nodes
that are of no concern to U-Boot.
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>