Now that we have a data section, add helper functions to save and fetch
per-CPU target PC.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

The secure monitor may need to store global or static values within the
secure section of memory, such as target PC or CPU power status.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

sunxi and i.mx7 both define the __secure modifier to put functions in
the secure section. Move this to a common place.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Both sun6i and sun7i have 64 KB of secure SRAM.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

As the PSCI implementation grows, we might exceed the size of the secure
memory that holds the firmware.

Add a configurable CONFIG_ARMV7_SECURE_MAX_SIZE so platforms can define
how much secure memory is available. The linker then checks the size of
the whole secure section against this.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

psci_text_end was used to calculate the PSCI stack address following the
secure monitor text. Now that we have an explicit secure stack section,
this is no longer used.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Now that we have a secure stack section that guarantees usable memory,
allocate the PSCI stacks in that section.

Also add a diagram detailing how the stacks are placed in memory.

Reserved space for the target PC remains unchanged. This should be
moved to global variables within a secure data section in the future.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Until now we've been using memory beyond psci_text_end as stack space
for the secure monitor or PSCI implementation, even if space was not
allocated for it.

This was partially fixed in ("ARM: allocate extra space for PSCI stack
in secure section during link phase"). However, calculating stack space
from psci_text_end in one place, while allocating the space in another
is error prone.

This patch adds a separate empty secure stack section, with space for
CONFIG_ARMV7_PSCI_NR_CPUS stacks, each 1 KB. There's also
__secure_stack_start and __secure_stack_end symbols. The linker script
handles calculating the correct VMAs for the stack section. For
platforms that relocate/copy the secure monitor before using it, the
space is not allocated in the executable, saving space.

For platforms that do not define CONFIG_ARMV7_PSCI_NR_CPUS, a whole page
of stack space for 4 CPUs is allocated, matching the previous behavior.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

The original PSCI implementation assumed CONFIG_ARMV7_PSCI_NR_CPUS=4.
Add this to platforms that have not defined it, using CONFIG_MAX_CPUS if
it is defined, or the actual number of cores for the given platform.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Targets that define CONFIG_ARMV7_SECURE_BASE will copy the secure section
to another address before execution.

Since the secure section in the u-boot image is only storage, there's
no reason to page align it and increase the binary image size.

Page align the secure section only when CONFIG_ARMV7_SECURE_BASE is not
defined. And instead of just aligning the __secure_start symbol, align
the whole .__secure_start section. This also makes the section empty,
so we need to add KEEP() to the input entry to prevent the section from
being garbage collected.

Also use ld constant "COMMONPAGESIZE" instead of hardcoded page size.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

sun7i has 2 CPUs.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

This patch finishes the rewrite of sunxi specific PSCI parts into C
code.

The assembly-only stack setup code has been factored out into a common
function for ARMv7. The GIC setup code can be renamed as psci_arch_init.
And we can use an empty stub function for psci_text_end.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Every platform has the same stack setup code in assembly as part of
psci_arch_init.

Move this out into a common separate function, psci_stack_setup, for
all platforms. This will allow us to move the remaining parts of
psci_arch_init into C code, or drop it entirely.

Also provide a stub no-op psci_arch_init for platforms that don't need
their own specific setup code.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

The Orange Pi Lite SBC is a small H3 based SBC, with 512MB RAM,
micro-sd slot, HDMI out, 2 USB-A connectors, 1 micro-USB connector,
sdio attached rtl8189ftv wifi and an ir receiver.

The dts file is identical to the one submitted to the upstream kernel.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NIan Campbell <ijc@hellion.org.uk>

This enables extra USB controllers which enable use of the 3rd USB
port on the new Orange Pi Plus 2E variant.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NIan Campbell <ijc@hellion.org.uk>

The Plus variant of the Orange Pi PC has an eMMC, add support for this.

Note we are using the same u-boot defconfig / dts for both the regular
Orange Pi PC as well as the Orange Pi PC Plus.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NIan Campbell <ijc@hellion.org.uk>

Now that we know that the BROM stores a value indicating the boot-source
at the beginning of SRAM, use that instead of trying to recreate the
BROM's boot probing.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NIan Campbell <ijc@hellion.org.uk>

We always define CONFIG_MISC_INIT_R on sunxi and misc_init_r is never
called in the spl, so the linker will optimize it and parse_spl_header(),
of which it is the only caller, away.

On the tests I've done (Orange Pi PC build) the SPL actually becomes
8 bytes smaller with this patch.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NIan Campbell <ijc@hellion.org.uk>

Currently we fill ethaddr with a fixed unique address based on the SoCs
serial (from the sid) to make sure that boards which use the integrated
emac / gmac get a fixed mac rather then a random one.

On some boards the wifi does not come with a fixed mac either, so we need
to also set eth1addr.

This commit changes the ethaddr setting code to check for ethernet%d
aliases (as fdt_fixup_ethernet does) and set an ethaddr variable for
all present aliases.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NIan Campbell <ijc@hellion.org.uk>

This patch add EMAC driver support for H3/A83T/A64 SoCs.
Tested on Pine64(A64-External PHY) and Orangepipc(H3-Internal PHY).

BIG Thanks to Andre for providing some of the DT code.
Signed-off-by: NAmit Singh Tomar <amittomer25@gmail.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

With a recent bunch of SD3.0 cards in our A20-based board we
experienced data transfer rates of about 250 KiB/s instead of 10 MiB/s
with previous cards from the same vendor (both 4 GB/class 10). By
increasing status register polling rate from 1 kHz to 1 MHz we were
able to reach the original transfer rates again. With the old cards
we now even reach about 16 MiB/s.
Signed-off-by: NTobias Doerffel <tobias.doerffel@ed-chemnitz.de>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

The patch converts one of the "reserved" fields in the sunxi SPL
header to a fel_uEnv_length entry. When booting over USB ("FEL
mode"), this enables the sunxi-fel utility to pass the string
length of uEnv.txt compatible data; at the same time requesting
that this data be imported into the U-Boot environment.

If parse_spl_header() in the sunxi board.c encounters a non-zero
value in this header field, it will therefore call himport_r() to
merge the string (lines) passed via FEL into the default settings.
Environment vars can be changed this way even before U-Boot will
attempt to autoboot - specifically, this also allows overriding
"bootcmd".

With fel_script_addr set and a zero fel_uEnv_length, U-Boot is
safe to assume that data in .scr format (a mkimage-type script)
was passed at fel_script_addr, and will handle it using the
existing mechanism ("bootcmd_fel").
Signed-off-by: NBernhard Nortmann <bernhard.nortmann@web.de>
Acked-by: NSiarhei Siamashka <siarhei.siamashka@gmail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Allwinner devices support SPI flash as one of the possible
bootable media type. The SPI flash chip needs to be connected
to SPI0 pins (port C) to make this work. More information is
available at:

    https://linux-sunxi.org/Bootable_SPI_flash

This patch adds the initial support for booting from SPI flash.
The existing SPI frameworks are not used in order to reduce the
SPL code size. Right now the SPL size grows by ~370 bytes when
CONFIG_SPL_SPI_SUNXI option is enabled.

While there are no popular Allwinner devices with SPI flash at
the moment, testing can be done using a SPI flash module (it
can be bought for ~2$ on ebay) and jumper wires with the boards,
which expose relevant pins on the expansion header. The SPI flash
chips themselves are very cheap (some prices are even listed as
low as 4 cents) and should not cost much if somebody decides to
design a development board with an SPI flash chip soldered on
the PCB.

Another nice feature of the SPI flash is that it can be safely
accessed in a device-independent way (since we know that the
boot ROM is already probing these pins during the boot time).
And if, for example, Olimex boards opted to use SPI flash instead
of EEPROM, then they would have been able to have U-Boot installed
in the SPI flash now and boot the rest of the system from the SATA
hard drive. Hopefully we may see new interesting Allwinner based
development boards in the future, now that the software support
for the SPI flash is in a better shape :-)

Testing can be done by enabling the CONFIG_SPL_SPI_SUNXI option
in a board defconfig, then building U-Boot and finally flashing
the resulting u-boot-sunxi-with-spl.bin binary over USB OTG with
a help of the sunxi-fel tool:

   sunxi-fel spiflash-write 0 u-boot-sunxi-with-spl.bin

The device needs to be switched into FEL (USB recovery) mode first.
The most suitable boards for testing are Orange Pi PC and Pine64.
Because these boards are cheap, have no built-in NAND/eMMC and
expose SPI0 pins on the Raspberry Pi compatible expansion header.
The A13-OLinuXino-Micro board also can be used.
Signed-off-by: NSiarhei Siamashka <siarhei.siamashka@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>

Upon further review this breaks most other platforms as we need to check
what core we're running on before touching it at all.

This reverts commit d73718f3.
Signed-off-by: NTom Rini <trini@konsulko.com>

With the change to set up pinctrl after relocation, link fails to boot. Add
a special case in the link code to handle this.

Fixes: d8906c1f (x86: Probe pinctrl driver in cpu_init_r())
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

Add support for Advantech SOM-DB5800 with the SOM-6867 installed.
This is very similar to conga-qeval20-qa3-e3845 in that there is a
reference carrier board (SOM-DB5800) with a Baytrail based SoM (SOM-6867)
installed.

Currently supported:
 - 2x UART (From ITE EC on SOM-6867) routed to COM3/4 connectors on
   SOM-DB5800.
 - 4x USB 2.0 (EHCI)
 - Video
 - SATA
 - Ethernet
 - PCIe
 - Realtek ALC892 HD Audio
   Pad configuration for HDA_RSTB, HDA_SYNC, HDA_CLK, HDA_SDO
   HDA_SDI0 is set in DT to enable HD Audio codec.
   Pin defaults for codec pin complexs are not changed.

Not supported:
 - Winbond Super I/O (Must be disabled with jumpers on SOM-DB8500)
 - USB 3.0 (XHCI)
 - TPM
Signed-off-by: NGeorge McCollister <george.mccollister@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

If global NVS says internal UART is not enabled, hide it in the ASL
code so that OS won't see it.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NGeorge McCollister <george.mccollister@gmail.com>
Tested-by: NGeorge McCollister <george.mccollister@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Now that platform-specific ACPI global NVS is added, pack it into
ACPI table and get its address fixed up.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NGeorge McCollister <george.mccollister@gmail.com>
Tested-by: NGeorge McCollister <george.mccollister@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

This introduces quark-specific ACPI global NVS structure, defined in
both C header file and ASL file.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

This introduces baytrail-specific ACPI global NVS structure, defined in
both C header file and ASL file.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NGeorge McCollister <george.mccollister@gmail.com>
Tested-by: NGeorge McCollister <george.mccollister@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

This patch adds support to enable and use the internal BayTrail UART
instead of the one integrated in the Super IO Winbond chip. For this,
a 2nd defconfig file is added.

This is useful for tests done for the congatec SoM used on baseboards
without such a Super IO chip.
Signed-off-by: NStefan Roese <sr@denx.de>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

For any FSP-enabled boards that want to enable debug UART support,
setup_internal_uart() will be called, but this API is only available
on BayTrail platform. Change to wrap it with CONFIG_INTERNAL_UART.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NStefan Roese <sr@denx.de>
Reviewed-by: NSimon Glass <sjg@chromium.org>

There are quite a number of BayTrail boards that uses an external
SuperIO chipset to provide the legacy UART. For such cases, it's
better to have a Kconfig option to enable the internal UART.

So far BayleyBay and MinnowMax boards are using internal UART as
the U-Boot console, enable this on these two boards.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NStefan Roese <sr@denx.de>
Reviewed-by: NSimon Glass <sjg@chromium.org>

For consistency with board_should_run_oprom(), do the same to
should_load_oprom(). Board support codes can provide this one
to override the default weak one.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

At present should_load_oprom() calls board_should_run_oprom() to
determine whether oprom should be loaded. But sometimes we just
want to load oprom without running. Make them independent.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

This option is defined at nowhere. Remove it.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

The following python error:

Traceback (most recent call last):
  File "./tools/patman/patman", line 144, in <module>
    series = patchstream.FixPatches(series, args)
  File "./tools/patman/patchstream.py", line 477, in FixPatches
    commit = series.commits[count]
IndexError: list index out of range

is seen when:

- 'END' is missing in those tags
- those tags are put in the last part in a commit message
- the commit is not the last commit of the series

Add testing logic to see if a new commit starts.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>

'Series-changes' uses blank line to indicate its end. If that is
missing, series internal state variable 'in_change' may be wrong.
Correct its state.
Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NSimon Glass <sjg@chromium.org>