Commit graph

20 commits

Author SHA1 Message Date
Andre Przywara
e32dad292a sunxi: dts: Fix typoed eMMC check
Commit 03510bf621 ("sunxi: only include alias for eMMC when mmc2
used") protected the eMMC alias in U-Boot's DT stub the with the
associated Kconfig symbol, but was actually using the wrong name.

Fix the name of the symbol to match what's defined in Kconfig and what
the defconfig files actually use.

Fixes: 03510bf621 ("sunxi: only include alias for eMMC when mmc2 used")
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reported-by: 5kft@5kft.org
Reviewed-by: Icenowy Zheng <icenowy@aosc.io>
2021-12-08 23:06:56 +00:00
Icenowy Zheng
03510bf621 sunxi: only include alias for eMMC when mmc2 used
Some Allwinner SoCs (e.g. R329) doesn't have a MMC2 controller at all,
and on boards that we do not utilize MMC2, the alias for it is just
useless.

Only include the alias when we specify CONFIG_MMC_SUNXI_EXTRA_SLOT to 2.

Signed-off-by: Icenowy Zheng <icenowy@sipeed.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2021-10-25 14:54:50 +01:00
Icenowy Zheng
001ec430be sunxi: decide the inclusion of SCP by SCP_ADDR existence
There are more Allwinner SoCs that do not have a SCP now.

When there's no SCP_ADDR macro defined, we can assume there's no SCP
available.

Drop the scp part of FIT description when SCP_ADDR does not exist.

Signed-off-by: Icenowy Zheng <icenowy@sipeed.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2021-08-01 00:11:34 +01:00
Andre Przywara
6785434709 sunxi: Bring back SD card as MMC device 0
Commit 2243d19e56 ("mmc: mmc-uclass: Use dev_seq() to read aliases
node's index") now actually enforces U-Boot's device enumeration policy,
where explicitly named devices come first, then any other non-named
devices follow, without filling gaps.

For quite a while we have had an "mmc1 = &mmc2;" alias in our
sunxi-u-boot.dtsi, which now leads to the problem that the SD card
(which was always mmc device 0) now gets to be number 2.
This breaks quite some boot scripts, including our own distro boot
commands, and some other features looking at $mmc_bootdev, also
fastboot.

Just add an explicit mmc0 alias in the very same file to fix this and
restore the old behaviour.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reported-by: Samuel Holland <samuel@sholland.org>
Tested-by: Simon Baatz <gmbnomis@gmail.com>
2021-05-31 00:39:54 +01:00
Samuel Holland
925cd8d77e sunxi: binman: Do not hardcode U-Boot load address
The FIT description has access to the configuration variables. Use the
appropriate variable instead of hardcoding the address.

Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2021-04-16 01:12:59 +01:00
Samuel Holland
ed4bc13f3d sunxi: binman: Respect the default FIT configuration
binman can fill in the default FIT configuration index as selected by
the "default-dt" argument, which is set to CONFIG_DEFAULT_DEVICE_TREE.
Let's respect the user's configuration by taking advantage of this
feature, instead of always defaulting to the first device tree in
CONFIG_OF_LIST.

Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2021-04-16 01:12:59 +01:00
Andre Przywara
c629ba854f sunxi: H616: Change TF-A load address to beginning of DRAM
Loading Trusted-Firmware's BL31 at 16KB into DRAM was originally a hack
to allow sharing more code with the other SoCs (which use this offset
in SRAM). However there is no longer a reason for that, as the
problematic macros have been properly separated there.

The latest (and hopefully final) TF-A code drop now changes the load
address to the beginning of DRAM, which is also more easily protected
by the Trustzone memory controller (code to be done).

Adjust the load address of BL31 now, to avoid any issues with
incompatible versions later on (the TF-A patches are about to be merged).

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Samuel Holland <samuel@sholland.org>
2021-03-31 09:50:05 +01:00
Jernej Skrabec
8ec293e063 sunxi: Add support for H616 SoC
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>
2021-01-25 21:52:01 +00:00
Samuel Holland
e72a6be4fc sunxi: binman: Add support for including SCP firmware
Allwinner sun50i SoCs contain an OpenRISC 1000 CPU that functions as a
System Control Processor, or SCP. ARM Trusted Firmware (ATF)
communicates with the SCP over SCPI to implement the PSCI system
suspend, shutdown and reset functionality. Currently, SCP firmware is
optional; the system will boot and run without it, but system suspend
will be unavailable.

Since all communication with the SCP is mediated by ATF, the only thing
U-Boot needs to do is load the firmware into SRAM. The SCP firmware
occupies the last 16KiB of SRAM A2, immediately following ATF.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
2020-10-22 11:43:43 +05:30
Samuel Holland
68158d59d2 sunxi: binman: Update FIT component descriptions
Since commit d879616e9e ("spl: fit: simplify logic for FDT loading for
non-OS boots"), the SPL looks at the "os" properties of FIT images to
determine where to append the FDT.

The "os" property of the "firmware" image also determines how to execute
the next stage of the boot process, as in 1d3790905d ("spl: atf:
introduce spl_invoke_atf and make bl31_entry private"). For this reason,
the next stage must be specified in "firmware", not in "loadables".

To support this additional functionality, and to properly model the boot
process, where ATF runs before U-Boot, add the "os" properties and swap
the firmware/loadable images in the FIT image.

Since this description was copied as an example in commit 70248d6a2916
("binman: Support generating FITs with multiple dtbs"), update those
examples as well for correctness and consistency.

Acked-by: Patrick Wildt <patrick@blueri.se>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
2020-10-22 11:43:43 +05:30
Samuel Holland
827c420c40 sunxi: binman: Use a macro for the BL31 load address
This consolidates the SoC-specific part at the top of the file to avoid
cluttering it up with preprocessor conditions.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
2020-10-22 11:43:43 +05:30
Samuel Holland
6b7c7ed80a sunxi: binman: Provide a default BL31 filename
Prior to commit 7f7f8aca8257 ("sunxi: Convert 64-bit boards to use
binman"), if the BL31 environment variable was not defined, the firmware
would be loaded from a file "bl31.bin" in the current directory. Restore
that behavior by providing that as the default filename in case no entry
arg is provided, which will be the case if the environment variable is
unset.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
2020-10-22 11:43:43 +05:30
Samuel Holland
eafbdbb8eb sunxi: binman: Fix spacing between nodes
Nodes should have a blank line separating them from sibling nodes and
properties. Add the necessary lines.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
2020-10-22 11:43:43 +05:30
Simon Glass
68de0679c9 binman: sunxi: Add help message for missing sunxi ATF BL31
Add a special help message pointing to the relevant README.

Signed-off-by: Simon Glass <sjg@chromium.org>
2020-09-22 12:54:13 -06:00
Simon Glass
cfa3db602c sunxi: Convert 64-bit boards to use binman
At present 64-bit sunxi boards use the Makefile to create a FIT, using
USE_SPL_FIT_GENERATOR. This is deprecated.

Update sunxi to use binman instead.

Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-09-22 12:50:43 -06:00
Jagan Teki
708b5da38a arm: dts: sunxi: Alter mmc2 auto-numbering to mmc1
Environment and fastboot mmc devices are configured based on the number
of mmc slots defined on particular board configs, MMC_SUNXI_SLOT_EXTRA.

If MMC_SUNXI_SLOT_EXTRA is more than 1, the default env and fastboot
mmc devices is mmc1 by assuming mmc0 is SD and mmc1 is emmc device.

But with DM_MMC the mmc devices are numbered as per the dts node
enablement. If there is a chance of having enabling all mmc nodes
in dts say mmc0, mmc1, mmc2 then the default env and fastboot devices
will failed to assign proper emmc device since mmc2 is emmc in most
of the Allwinner platforms.

So, we need to alter the auto-numbering by aliasing mmc2 to mmc1 since
aliases take precedence over auto-numbering.

If the dts enables mmc0, mmc1, mmc2, then all the nodes will probe
sequentially and auto-numbered as it is. but when aliases mmc1 with mmc2
the resulting number should be that mmc0 is till mmc0, mmc2 become mmc1
and mmc2 become mmc1

Without aliases of mmc1 = &mmc2;
-------------------------------
MMC:   mmc@1c0f000: 0, mmc@1c10000: 1, mmc@1c11000: 2

With aliases of mmc1 = &mmc2;
----------------------------
MMC:   Device 'mmc@1c11000': seq 1 is in use by 'mmc@1c10000'
mmc@1c0f000: 0, mmc@1c10000: 2, mmc@1c11000: 1
Loading Environment from FAT... OK

Some platforms like A20 has mmc0...mmc3, but there is no usecases now
for enabling all mmc controllers in any of A20 board dts files.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
2019-01-30 18:22:18 +05:30
Simon Glass
3ab9598df7 binman: Rename 'position' to 'offset'
After some thought, I believe there is an unfortunate naming flaw in
binman. Entries have a position and size, but now that we support
hierarchical sections it is unclear whether a position should be an
absolute position within the image, or a relative position within its
parent section.

At present 'position' actually means the relative position. This indicates
a need for an 'image position' for code that wants to find the location of
an entry without having to do calculations back through parents to
discover this image position.

A better name for the current 'position' or 'pos' is 'offset'. It is not
always an absolute position, but it is always an offset from its parent
offset.

It is unfortunate to rename this concept now, 18 months after binman was
introduced. However I believe it is the right thing to do. The impact is
mostly limited to binman itself and a few changes to in-tree users to
binman:

   tegra
   sunxi
   x86

The change makes old binman definitions (e.g. downstream or out-of-tree)
incompatible if they use the 'pos = <...>' property. Later work will
adjust binman to generate an error when it is used.

Signed-off-by: Simon Glass <sjg@chromium.org>
2018-08-01 16:30:06 -06:00
Maxime Ripard
3def2f8dbb Revert "sunxi: binman: Add U-Boot binary size check"
This reverts commit 819f1e081c.

This check was introduced in order to cope with the size limitation we had
when we were still using the raw environment in MMC. However, this
introduces padding as well, which can result in an overly huge binary if
one wants to flash the environment to some other location.

Since we now have a FAT-based environment, this check is not so useful
anymore, so we can just drop it.

Cc: Andre Przywara <andre.przywara@arm.com>
Cc: Måns Rullgård <mans@mansr.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
2018-05-25 14:55:07 +05:30
Maxime Ripard
819f1e081c sunxi: binman: Add U-Boot binary size check
The U-Boot binary may trip over its actual allocated size in the storage.
In such a case, the environment will not be readable anymore (because
corrupted when the new image was flashed), and any attempt at using saveenv
to reconstruct the environment will result in a corrupted U-Boot binary.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
2017-10-25 10:05:06 +02:00
Simon Glass
61b994a386 sunxi: Use binman for sunxi boards
Move sunxi boards to use binman. This involves adding the image definition
to the device tree and using it in the Makefile.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
2016-12-20 08:09:55 +13:00