This target is used for Allwinner's sun20i series of RISC-V SoCs,
starting with the Allwinner D1 and D1s.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Now that the PMIC has a DM driver and binds device tree subnodes, the
GPIO device can be bound that way, instead of from inside board code.
Since the driver still uses the single set of register definitions from
axpXXX.h (as selected by AXPxxx_POWER), it does not differentiate among
the supported compatibles.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Now that the sunxi_gpio driver handles pull-up/down via the driver
model, we can switch to DM_GPIO for these pins with no loss in
functionality. Since the driver now gets its pin configuration from
the device tree, we can remove the Kconfig symbols.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Now that the USB PHY driver uses the device tree to get VBUS supply
regulators, these Kconfig symbols are unused. Remove them.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Some RISC-V CPUs, such as the T-HEAD XuanTie series, have a
vendor-specific way to invalidate a portion of the instruction cache.
Allow them to override invalidate_icache_range().
Series-to: Rick Chen <rick@andestech.com>
Series-to: Leo <ycliang@andestech.com>
Series-cc: u-boot@lists.denx.de
Signed-off-by: Samuel Holland <samuel@sholland.org>
This is required on CPUs which always operate in CLIC mode, such as the
T-HEAD E906 and E907. Per the CLIC specification: "In this mode, the
trap vector base address held in mtvec is constrained to be aligned on a
64-byte or larger power-of-two boundary."
Series-to: Rick Chen <rick@andestech.com>
Series-to: Leo <ycliang@andestech.com>
Series-cc: u-boot@lists.denx.de
Reported-by: Madushan Nishantha <jlmadushan@gmail.com>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Clean things up for the next time somebody adds a target.
Series-to: Rick Chen <rick@andestech.com>
Series-to: Leo <ycliang@andestech.com>
Series-cc: u-boot@lists.denx.de
Signed-off-by: Samuel Holland <samuel@sholland.org>
The MMC controller driver is (and ought to be) the only user of these
register definitions. Put them in a header next to the driver to remove
the dependency on a specific ARM platform's headers.
Due to the sunxi_mmc_init() prototype, the file was not renamed. None of
the register definitions were changed.
Series-to: sunxi
Signed-off-by: Samuel Holland <samuel@sholland.org>
Now that 32-bit SoCs can load U-Boot proper (and possibly other
firmware) from a FIT, use this method by default. SPL_FIT_IMAGE_TINY is
required to stay within the 24 or 32 KiB SPL size limit on early SoCs;
for consistency, enable it everywhere.
Series-to: Andre Przywara <andre.przywara@arm.com>
Series-to: Jagan Teki <jagan@amarulasolutions.com>
Series-cc: Icenowy Zheng <icenowy@aosc.io>
Series-cc: Jesse Taube <Mr.Bossman075@gmail.com>
Series-cc: u-boot@lists.denx.de
Series-version: 3
Commit-changes: 2
- New patch for v2, split from the .dtsi changes
Cover-changes: 3
- Rebased and collected tags
Cover-letter:
sunxi: SPL FIT support for 32-bit sunxi SoCs
This series makes the necessary changes so 32-bit sunxi SoCs can load
additional device trees or firmware from SPL along with U-Boot proper.
Crust (SCP firmware) has support for A33 and H3, and H3 also needs to
load an eGon blob to support CPU 0 hotplug (a silicon bug workaround).
FIT unlocks more features (signatures, multiple DTBs, etc.), so enable
it by default. A10 (sun4i) only has 24 KiB of SRAM A1, so it needs
SPL_FIT_IMAGE_TINY. For consistency, enable that option everywhere.
After this series is applied, we can increase SPL_MAX_SIZE for H6 and
newer SoCs, both 32-bit (e.g. A50, T113) and 64-bit. I did not do that
yet because there is some discussion to be had about the correct value:
it must be adjusted to guarantee return-to-FEL functionality, and the
exact adjustment depends on the sunxi-fel tool implementation.
END
Signed-off-by: Samuel Holland <samuel@sholland.org>
Some 32-bit SoCs can use SCP firmware to implement additional PSCI
functionality, such as system suspend. In order to load this firmware
from SPL, we need to generate and use a FIT instead of a legacy image.
Adjust the binman FIT definition so it does not rely on TF-A BL31, as
this is not used on 32-bit SoCs. Instead, after loading the firmware,
U-Boot proper is executed directly.
Series-changes: 2
- Rely on binman min-size instead of using explicit offsets
- Use Kconfig for firmware addresses instead of an #ifdef staircase
Signed-off-by: Samuel Holland <samuel@sholland.org>
This is easier to read than the #ifdef staircase, provides better
visibility into the memory map (alongside the other Kconfig
definitions), and allows these addresses to be reused from code.
Commit-changes: 2
- New patch for v2, split from the .dtsi changes
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
This excludes options that are inherently ARM-specific or are specific
to legacy non-DM drivers.
Some help text is cleaned up along the way.
Signed-off-by: Samuel Holland <samuel@sholland.org>
This keeps all of the defaults for sunxi platforms in one place. Most of
these only depend on architecture-independent features of the SoC (clock
tree or SRAM layout) anyway.
No functional change; just some minor help text cleanup.
Signed-off-by: Samuel Holland <samuel@sholland.org>
This was already supported by every machine type. It is unlikely that
any new SoC support will be added without SPL support.
Signed-off-by: Samuel Holland <samuel@sholland.org>
To maintain consistent behavior across architectures, most of the
options selected by ARCH_SUNXI should be selected for the D1 SoC as
well. To accomplish this, select them from BOARD_SUNXI instead.
No functional change here. Lines are only moved and alphabetized.
Signed-off-by: Samuel Holland <samuel@sholland.org>
With the introduction of the Allwinner D1, the sunxi board family now
spans multiple architectures (ARM and RISC-V). Since ARCH_SUNXI depends
on ARM, it cannot be used to gate architecture-independent options.
Specifically, this means the board Kconfig file cannot be sourced from
inside the "if ARCH_SUNXI" block.
Introduce a new BOARD_SUNXI symbol that can be selected by both
ARCH_SUNXI now and the new RISC-V SoC symbols when they are added, and
use it to gate the architecture-independent board options.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Some of the selected symbols have a user-visible dependency. Make the
selections conditional on that dependency to avoid creating invalid
configurations.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Two of these selections are redundant and have no effect:
- DM_KEYBOARD is selected by USB_KEYBOARD
- DM_MMC is selected by MMC
This selection has no effect by default and is unnecessarily strong:
- USB_STORAGE is implied by DISTRO_DEFAULTS
Signed-off-by: Samuel Holland <samuel@sholland.org>
We tried to enable USB_EHCI_GENERIC and USB_OHCI_GENERIC by default.
This did not work because those symbols depend on USB_EHCI_HCD and
USB_OHCI_HCD, which were not enabled. Fix this by implying all four.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Similar change was done by commit b4c2c151b14b ("Kconfig: Remove all
default n/no options") and again sync is required.
default n/no doesn't need to be specified. It is default option anyway.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Svyatoslav Ryhel <clamor95@gmail.com> # tegra
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Angelo Dureghello <angelo@kernel-space.org>
When building a non-SPL image, relocation is needed. This patch restores
the old behaviour before commit b35316fb67cb ("Convert
CONFIG_SPL_INIT_MINIMAL et al to Kconfig") was only defined if
CONFIG_SPL_BUILD was defined.
Fixes: b35316fb67cb ("Convert CONFIG_SPL_INIT_MINIMAL et al to Kconfig")
Signed-off-by: Martin Fäcknitz <faecknitz@hotsplots.de>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEgWII69YpahbL5iK5gS8AYozs+qIFAmU7j50ACgkQgS8AYozs
+qIh8w/+O4UjT0sG1NLwmyV7U1Ypk+EyYaE6wmSWzpsJLfH/YvtObBJOYRuXxRVh
J9lkgCsw8Ct1ZNCrp8iVO+Dz1DtV8+QvTecrUHZqcOhTYDaqxXnlvEH2/EUhgo5T
9a/ZaDtOP1mKz754C4G6G363+iRCvbcqDECeKg9VYxfWCo1cINOmqyQCqlGxFT+h
PKiB5VzUpN/K/yiie+Hr42/+6XaykAUjUvEWeyKOsRmYY4lNiK22vG/puE42bFTh
catXwTE2a7x+yzPKkdhR0UGvDUlIKET2kF6mi+pYN2h/cSUxWTzbP/OxcU9yJOnm
qJiRZ+Woez1I7ul6ln4ci2kiWc3CTYFXfctwrBJPuJ/EO+2EEb3oHqG2S3Fc9VBZ
N17flHW7XZHEQbNexlUhk9cRpCwRuSA5OJXwW+IZIuydgNeo3xF0iYvipbjkEGgW
BBkt8PH+ivTLjEz6Gcmquvo1fHGJLHRIPg7DNb0phGHviuC0zlDJ7N5DZk0CpkiT
36siV9xK4X6qvWkOTa6Ldw60e4tN9nv3VG30uXtPHi3XdOkKfNkyIuqO/5BkkQPt
6yEc9IYXYoWNKDVUGme5+xszZp1sSvqltajG9VVNupt958dFyOSgS5aNa6B4UsWX
3XfndP1/s2bezUHoQx5zjraapKVrqBFLkGeTlCDUD+mEgP440G8=
=gvDs
-----END PGP SIGNATURE-----
Merge tag 'tpm-next-27102023' of https://source.denx.de/u-boot/custodians/u-boot-tpm
bootX measurements and measurement API moved to u-boot core:
Up to now, U-Boot could perform measurements and EventLog creation as
described by the TCG spec when booting via EFI.
The EFI code was residing in lib/efi_loader/efi_tcg2.c and contained
both EFI specific code + the API needed to access the TPM, extend PCRs
and create an EventLog. The non-EFI part proved modular enough and
moving it around to the TPM subsystem was straightforward.
With that in place we can have a common API for measuring binaries
regardless of the boot command, EFI or boot(m|i|z), and contructing an
EventLog.
I've tested all of the EFI cases -- booting with an empty EventLog and
booting with a previous stage loader providing one and found no
regressions. Eddie tested the bootX part.
Eddie also fixed the sandbox TPM which couldn't be used for the EFI code
and it now supports all the required capabilities. This had a slight
sideeffect in our testing since the EFI subsystem initializes the TPM
early and 'tpm2 init' failed during some python tests. That code only
opens the device though, so we can replace it with 'tpm2 autostart'
which doesn't error out and still allows you to perfom the rest of the
tests but doesn't report an error if the device is already opened.
There's a few minor issues with this PR as well but since testing and
verifying the changes takes a considerable amount of time, I prefer
merging it now.
Heinrich has already sent a PR for -master containing "efi_loader: fix
EFI_ENTRY point on get_active_pcr_banks" and I am not sure if that will
cause any conflicts, but in any case they should be trivial to resolve.
Both the EFI and non-EFI code have a Kconfig for measuring the loaded
Device Tree. The reason this is optional is that we can't reason
when/if devices add random info like kaslr-seed, mac addresses etc in
the DT. In that case measurements are random, board specific and
eventually useless. The reason it was difficult to fix it prior to this
patchset is because the EFI subsystem and thus measurements was brought
up late and DT fixups might have already been applied. With this
patchset we can measure the DT really early in the future.
Heinrich also pointed out that the two Kconfigs for the DTB measurements
can be squashed in a single one and that the documentation only explains
the non-EFI case. I agree on both but as I said this is a sane working
version, so let's pull this first it's aleady big enough and painful to
test.
Use the sandbox TPM driver to measure some boot images in a unit
test case.
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Disarm the error message forcing u-boot/spl image to be located at
sector 0 on eMMC data-partition and microSD.
Offset 0 makes sense on eMMC boot partitions only, data partition must
use 4096 to avoid conflicting with MBR.
Valid offsets when booting from microSD, reported by boot-rom v1.73:
BootROM: Bad header at offset 00000200
BootROM: Bad header at offset 00004400
BootROM: Bad header at offset 00200000
BootROM: Bad header at offset 00400000
BootROM: Bad header at offset 00600000
BootROM: Bad header at offset 00800000
BootROM: Bad header at offset 00A00000
BootROM: Bad header at offset 00C00000
BootROM: Bad header at offset 00E00000
BootROM: Bad header at offset 01000000
BootROM: Bad header at offset 01200000
BootROM: Bad header at offset 01400000
BootROM: Bad header at offset 01600000
BootROM: Bad header at offset 01800000
BootROM: Bad header at offset 01A00000
BootROM: Bad header at offset 01C00000
BootROM: Bad header at offset 01E00000
BootROM: Bad header at offset 02000000
BootROM: Bad header at offset 02200000
BootROM: Bad header at offset 02400000
BootROM: Bad header at offset 02600000
BootROM: Bad header at offset 02800000
BootROM: Bad header at offset 02A00000
BootROM: Bad header at offset 02C00000
BootROM: Bad header at offset 02E00000
Valid offsets when booting from eMMC:
BootROM: Bad header at offset 00000000
BootROM: Bad header at offset 00200000
Switching BootPartitions.
BootROM: Bad header at offset 00000000
BootROM: Bad header at offset 00200000
Fixes: 2226ca17348 ("arm: mvebu: Load U-Boot proper binary in SPL code based on kwbimage header")
Signed-off-by: Josua Mayer <josua@solid-run.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Extend Turris Mox board code to support CZ.NIC's RIPE Atlas Probe.
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
SCMI power domain management protocol is supported on sandbox
for test purpose. Add fake agent interfaces and associated
power domain devices.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Current code allows up to 3 MBR partitions without extended one.
If more than 3 partitions are required, then extended partition(s)
must be used.
This commit allows up to 4 primary MBR partitions without the
need for extended partition.
Add mbr test unit. In order to run the test manually, mmc6.img file
of size 12 MiB or greater is required in the same directory as u-boot.
Test also runs automatically via ./test/py/test.py tool.
Running mbr test is only supported in sandbox mode.
Signed-off-by: Alex Gendin <agendin@matrox.com>
[ And due to some further changes for testing ]
Signed-off-by: Simon Glass <sjg@chromium.org>
We can remove common.h from most cases of the code here, and only a few
places need an additional header instead.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Rick Chen <rick@andestech.com>
We can remove common.h from most cases of the code here, and only a few
places need an additional header instead.
Signed-off-by: Tom Rini <trini@konsulko.com>
We can remove common.h from most cases of the code here, and only a few
places need an additional header instead.
Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Michal Simek <michal.simek@amd.com>
We can remove common.h from most cases of the code here, and only a few
places need an additional header instead.
Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Angelo Dureghello <angelo@kernel-space.org>
We can remove common.h from most cases of the code here, and only a few
places need an additional header instead.
Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Alexey Brodkin <abrodkin@synopsys.com>
- Add Board: rk3588 NanoPC-T6, Orange Pi 5, Orange Pi 5 Plus;
- clk driver fix for rk3568 and rk3588;
- rkmtd cmd support for rockchip nand device;
- dts update and sync from linux;
Xunlong Orange Pi 5 Plus is a single-board computer based on the
Rockchip RK3588 SoC. The board provides abundant interfaces, including
two HDMI output ports, one HDMI input port, two 2.5G Ethernet ports,
M.2 M-Key slot, M.2 E-Key slot, two USB 3.0, two USB 2.0, and two Type-C.
Features tested on a Orange Pi 5 Plus 4GB v1.2:
- SD-card boot
- eMMC boot
- SPI Flash boot
- PCIe/NVMe
- USB 2.0 host
- Ethernet
Device tree is imported from linux v6.7-rockchip-dts64-1 tag.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Xunlong Orange Pi 5 is a single-board computer based on the Rockchip
RK3588S SoC. The board provides abundant interfaces, HDMI output, GPIO
interface, M.2 PCIe2.0, Type-C, Gigabit LAN port, 2*USB2.0, 1*USB3.0,
etc.
Features tested on a Orange Pi 5 4GB v1.2:
- SD-card boot
- SPI Flash boot
- PCIe/NVMe
- USB 2.0 host
- Ethernet
Device tree is imported from linux v6.7-rockchip-dts64-1 tag.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The device tree for rk3588 and rock-5b contain usb3 nodes that have
deviated too much from current state of submitted mainline linux usb3
patches, see [1].
Sync usb3 related nodes from latest patches and collaboras rk3588 tree
so that dwc3-generic driver can be updated to include support for the
rockchip,rk3588-dwc3 compatible in the future, use rockchip,rk3568-dwc3
compatible until final node is merged in linux maintainer tree.
[1] https://lore.kernel.org/lkml/20231009172129.43568-1-sebastian.reichel@collabora.com/
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
