Now that this functionality is modeled using the device tree and
regulator uclass, the named GPIO is not referenced anywhere. Remove it.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Some SoCs of the H616 family use a die variant, that puts some CPU power
and reset control registers at a different address. There are examples
of two instances of the same board, using different die revisions of the
otherwise same H313 SoC. We need to write to a register in that block
*very* early in the SPL boot, to switch the core to AArch64.
Since the devices are otherwise indistinguishable, let the SPL code read
that die variant and use the respective RVBAR address based on that.
That is a bit tricky, since we need to do that in hand-coded AArch32
machine language, shared by all 64-bit SoCs. To avoid build dependencies
in this mess, we always provide two addresses to choose from, and just
give identical values for all other SoCs. This allows the same code to
run on all 64-bit SoCs, and controls this switch behaviour purely from
Kconfig.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
To switch the ARMv8 Allwinner SoCs into the 64-bit AArch64 ISA, we need
to program the 64-bit start code address into an MMIO mapped register
that shadows the architectural RVBAR register.
This address is SoC specific, with just two versions out there so far.
Now a third address emerged, on a *variant* of an existing SoC (H616).
Change the boot0.h start code to make this address a Kconfig
selectable option, to allow easier maintenance.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
It turns out that some H616 and related SoCs (like H313) need TPR2
parameter for proper working. Add it.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Part of the code, previously known as "unknown feature", also doesn't
have constant values. They are derived from TPR0 parameter in vendor
DRAM code.
Let's move that code to separate function and introduce TPR0 parameter
here too, to ease adding new boards.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Acked-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
These values are highly board specific and thus make sense to add
parameter for them. To ease adding support for new boards, let's make
them same as in vendor DRAM settings.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Acked-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Vendor DRAM settings use TPR10 parameter to enable various features.
There are many mores features that just those that are currently
mentioned. Since new will be added later and most are not known, let's
reuse value from vendor DRAM driver as-is. This will also help adding
support for new boards.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
While ODT values for same memory type are similar, they are not
necessary the same. Let's parameterize them and make parameter same as
in vendor DRAM settings. That way it will be easy to introduce new board
support.
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
At this point, the remaining places where we have a symbol that is
defined as CONFIG_... are in fairly odd locations. While as much dead
code has been removed as possible, some of these locations are simply
less obvious at first. In other cases, this code is used, but was
defined in such a way as to have been missed by earlier checks. Perform
a rename of all such remaining symbols to be CFG_... rather than
CONFIG_...
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The rest of the unmigrated CONFIG symbols in the CONFIG_SYS namespace do
not easily transition to Kconfig. In many cases they likely should come
from the device tree instead. Move these out of CONFIG namespace and in
to CFG namespace.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The current name is inconsistent with SPL which uses CONFIG_SPL_TEXT_BASE
and this makes it imposible to use CONFIG_VAL().
Rename it to resolve this problem.
Signed-off-by: Simon Glass <sjg@chromium.org>
H6 and H616 SPL code has a few writes to unknown PRCM registers. Now
that we know what they are, let's replace magic offsets with proper
register names.
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Reviewed-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Fix non working console on uart2, that seems releated to both
Allwinner H2+ and H3.
Signed-off-by: Angelo Dureghello <angelo.dureghello@timesys.com>
[Andre: remove H2+, rearrange pin setup order]
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
SPL uses the image header to detect the boot device and to find the
offset of the next U-Boot stage. Since this information is stored
differently in the eGON and TOC0 image headers, add code to find the
correct value based on the image type currently in use.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
This is now handled automatically by the pinctrl driver.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
These options are not currently enabled anywhere. Any new users should
use DM clocks and pinctrl.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
This is now handled automatically by the pinctrl driver.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
This is now handled automatically by the pinctrl driver.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Create a do-nothing driver for each sunxi pin controller variant.
Since only one driver can automatically bind to a DT node, since the
GPIO driver already requires a manual binding process, and since the
pinctrl driver needs access to some of the same information, refactor
the GPIO driver to be bound by the pinctrl driver. This commit should
cause no functional change.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
The SUNIV SoCs come with a sun6i-style SPI controller at the base address
of sun4i SPI controller. The module clock of the SPI controller is
missing which leaves us running directly from the AHB clock, which is
set to 200MHz.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
[Icenowy: Original implementation]
Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com>
[Jesse: adaptation to Upstream U-Boot]
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
In contrast to other Allwinner SoCs the F1C100s BROM does not store a
boot source indicator in the eGON header in SRAM. This leaves the SPL
guessing where we were exactly booted from, and for instance trying
the SD card first, even though we booted from SPI flash.
By inspecting the BROM code and by experimentation, Samuel found that the
top of the BROM stack contains unique pointers for each of the boot
sources, which we can use as a boot source indicator.
This patch removes the existing board_boot_order bodge and replace it
with a proper boot source indication function.
The only caveat is that this only works in the SPL, as the SPL header
gets overwritten with the exception vectors, once U-Boot proper takes
over. Always return MMC0 as the boot source, when called from U-Boot
proper, as a placeholder for now, until we find another way.
Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com>
Suggested-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Add support for F1C100s internal dram controller.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
This patch aims to add header files for the suniv.
The header files included add support for uart, and clocks.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Jesse Taube <Mr.Bossman075@gmail.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Currently we do some magic "SRAM setup" MMIO writes in s_init(), copied
from the original BSP U-Boot. The comment speaks of this being required
before DRAM access gets enabled, but there is no indication that this
would actually be required that early.
Move this out of s_init(), into board_init_f(). Since this actually only
affects a very few older SoCs, the actual code goes into the cpu/armv7
directory, to move it out of the way for all other SoCs.
This also uses the opportunity to convert some #ifdefs over to the fancy
IS_ENABLED() macros used in actual C code.
We keep the s_init() stub around for now, since armv8's lowlevel_init
still relies on it.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
The GPIO and pinctrl drivers need these setters for pin configuration.
Since they are DM drivers, they should not be using hardcoded base
addresses. Factor out variants of the setter functions which take a
pointer to the GPIO bank's MMIO registers.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
The return values of these functions are always zero, and they are
never checked. Since they are not needed, remove them.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Since the beginning, all banks have had space for 32 pins, even when
not all pins were implemented. Let's use a single constant for the GPIO
bank size here, like the GPIO driver is already doing.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
This clarifies which callers must be updated to complete the DM_GPIO
conversion.
The only remaining caller of name_to_gpio in generic code is inside the
!DM_GPIO block in cmd/gpio.c. DM_GPIO is always selected on sunxi, so
that code cannot be reached. And after this commit, there are only two
remaining implementations of name_to_gpio.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
The only caller of this function was the MMC pinmux code, which used it
to parse a string given from a Kconfig symbol. As the Kconfig symbol has
been converted to a Boolean, this function is no longer needed.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Only one board, Yones Toptech BD1078, actually uses a non-default MMC
pinmux. All other uses of these symbols select the default value or an
invalid value. To simplify things, remove support for the unused pinmux
options, and convert the remaining option to a Boolean.
This allows the pinmux to be chosen by the preprocessor, instead of
having the code parse a string at runtime (for a build-time option!).
Not only does this reduce code size, but it also allows this Kconfig
option to be used in a table-driven DM pinctrl driver.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
The CCU header is only used by the DM drivers, not any platform code.
Its current location adds an artificial dependency on CONFIG_ARM and
ARCH_SUNXI, which will be problematic when adding the CCU driver for
a RISC-V sunxi platform.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
So far for the H3, A23, and A33 SoCs, we use DRAM to hold the secure
monitor code (providing PSCI runtime services). And while those SoCs do
not have the secure SRAM B like older SoCs, there is enough (secure)
SRAM A2 to put the monitor code and data in there instead.
Follow the design of 64-bit SoCs and use the first part for the monitor,
and the last 16 KiB for the SCP firmware. With this change, the monitor
no longer needs to reserve a region in DRAM.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
[Andre: amend commit message, fix R40 and V3s build]
Signed-off-by: Andre Przywara <andre.przywara@arm.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: Andre Przywara <andre.przywara@arm.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: Andre 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: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Previously we have known that R40 has a configuration register for its
rank 1, which allows different configuration than rank 0. Reverse
engineering of newest libdram of A64 from Allwinner shows that A64 has
this register too. It's bit 0 (which enables dual rank in rank 0
configuration register) means a dedicated rank size setup is used for
rank 1.
Now, Pine64 scheduled to use a 3GiB LPDDR3 DRAM chip (which has 2GiB
rank 0 and 1GiB rank 1) on PinePhone, that makes asymmetric dual rank
DRAM support necessary.
Add this support. The code could support both A64 and R40, but because
dual rank detection is broken on R40 now, we cannot really use it on R40
currently.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
The A23, A33, H3, H5, A83T, V3 and Sochip S3 sun8i SoCs can mux uart1 on
GPIOs PG6 and PG7. This patch adds support for using uart1 on those pins
as boot console.
Signed-off-by: Tobias Schramm <t.schramm@manjaro.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
H616 is very similar to H6 so most of the infrastructure can be reused.
However, two big differences are that it doesn't have functional SRAM A2
which is usually used for TF-A and it doesn't have ARISC co-processor.
It also needs bigger SPL size - 48 KiB.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Allwinner H616 supports many types of DRAM. Most notably it supports
LPDDR4. However, all commercially available boards at this time use
only DDR3, so this commit adds only DDR3 support.
Controller and MBUS are very similar to H6 but PHY is completely
unknown.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Acked-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
This port is needed for communication with PMIC. SPL uses it to set DRAM
voltage on H616 boards.
Reviewed-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
This port is used for debug terminal on all known H616 boards.
Reviewed-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
H616 has mostly the same clocks as H6 with some small differences. Just
reuse H6 clocks for H616 and handle differences with macros.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
I2C support, especially R_I2C port, will be needed in future. Upcoming
support for H616 will need R_I2C to adjust DRAM voltage.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
There was no need to have prcm definitions for H6 and similar SoCs till
now. However, support R_I2C will be needed soon in SPL.
Move old definitions to prcm_sun6i.h and add new ones in prcm_sun50i.h.
One of those files will be selected in common prcm.h based on defined
macros.
This commit doesn't do any functional change.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
It turns out that several SoCs share same mmc configuration as H6. In
order to lower ifdef clutter replace H6 specific macro with common one.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
It turns out that there are at least 2 other SoCs which have basically
the same memory map, similar clocks and other features as H6. It's very
likely that we'll see more such SoCs in the future. In order to ease
porting to new SoCs and lower ifdef clutter, introduce common symbol for
them.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
So far we did not support the BootROM based FEL USB debug mode on the
64-bit builds for Allwinner SoCs: The BootROM is using AArch32, but the
SPL runs in AArch64.
Returning back to AArch32 was not working as expected, since the RMR
reset into 32-bit mode always starts execution in the BootROM, but not
in the FEL routine.
After some debug and research and with help via IRC, the CPU hotplug
mechanism emerged as a solution: If a certain R_CPUCFG register contains
some magic, the BootROM will immediately branch to an address stored in
some other register. This works well for our purposes.
Enable the FEL feature by providing early AArch32 code to first save the
FEL state, *before* initially entering AArch64.
If we eventually determine that we should return to FEL, we reset back
into AArch32, and use the CPU hotplug mechanism to run some small
AArch32 code snippet that restores the initially saved FEL state.
That allows the normal AArch64 SPL build to be loaded via the sunxi-fel
tool, with it returning into FEL mode, so that other payloads can be
transferred via FEL as well.
Tested on A64, H5 and H6.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Priit Laes <plaes@plaes.org> (on Olimex A64-Olinuxino)
The is_boot0_magic macro is missing parentheses around the macro
argument, breaking any usage with a more complex argument.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
