reg must contain enough cells for the entire next address/size pair
after skipping `index` pairs. The previous code allows an out-of-bounds
read when na + ns > 1.
Series-to: Simon Glass <sjg@chromium.org>
Fixes: 69b41388ba45 ("dm: core: Add a new api to get indexed device address")
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.
Signed-off-by: Samuel Holland <samuel@sholland.org>
This provides a unified configuration across all sunxi boards,
regardless of CPU architecture.
Series-to: Andre Przywara <andre.przywara@arm.com>
Series-to: Jagan Teki <jagan@amarulasolutions.com>
Series-cc: u-boot@lists.denx.de
Cover-letter:
sunxi: Prepare platform Kconfig to support multiple architectures
sunxi is getting a new RISC-V platform, D1. We want to share as much of
the existing configuration as possible, to provide a familiar
environment, DRAM layout, partition layout, etc.
Because U-Boot includes all architecture Kconfig files at once, we must
use a symbol outside of both CONFIG_ARM and CONFIG_RISCV to contain
shared Kconfig options. I chose BOARD_SUNXI, corresponding to the file
location and somewhat following the BOARD_SPECIFIC_OPTIONS pattern.
I did a buildman run on this series. The only net option changes are the
expected ones:
- Host-side USB gets enabled on several boards by the first patch
(emlid_neutis_n5_devboard orangepi_zero2 pinephone pinetab tanix_tx6
x96_mate teres_i)
- CONFIG_BOARD_SUNXI gets added everywhere
- CONFIG_SYS_I2C_MVTWSI gets enabled by the corresponding patch
Andre, please feel free to take any subset of these; they don't all have
to go in at once. And I'm open to suggestions about what instances of
ARCH_SUNXI should (not) be converted. Some of them are open to opinion.
I left alone the options in arch/arm/mach-sunxi/Kconfig that are covered
by other series (MMC CD/USB PHY/power pins, AXP GPIO).
After this series, the Kconfig changes needed for D1 support are quite
small, something like this commit:
c12cf6c5d7.patch
Adding SUNXI_MINIMUM_DRAM_MB certainly made things nicer. There are a
few options that probably still need some adjustment to respect it.
END
Signed-off-by: Samuel Holland <samuel@sholland.org>
For legacy reasons we were defining the card detect GPIO for all sunxi
boards in each board's defconfig.
There is actually no need for a card-detect check in the SPL code (which
consequently has been removed already), and also in U-Boot proper we
have DM code to query the CD GPIO name from the device tree.
That means we don't have any user of that information left, so can
remove the definitions from the defconfigs.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
As the SPL code for sunxi boards does not use the driver model, we have
two mmc_ops structures, one for DM, one for non-DM. The actual hardware
access code is shared, with the respective callback functions using that
common code.
To make this more obvious and easier to read, reorder the functions to
group them: we first have the common code, then the non-DM bits, and
the proper DM implementation at the end.
Also document this structure in the comment at the beginning of the file.
No functional change intended.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
The sunxi MMC code does not use the DM in the SPL, as we don't have a
device tree available that early, also no space for it.
This also means we cannot access the card-detect GPIO information from
there, so we have Kconfig symbols called CONFIG_MMCx_CD_PIN, which each
board has to define. This is a burden, also requires extra GPIO code in
the SPL.
As the SPL is the natural successor of the BootROM (from which we are
loaded), we can actually ignore the CD pin completely, as this is what
the BootROM does as well: CD GPIOs are board specific, but the BootROM
is not, so accesses the MMC devices anyway.
Remove the card detect code from the non-DM implementation of the sunxi
MMC driver, to get rid of this unneeded code.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
This ensures the same environment layout will be used across all sunxi
boards, regardless of CPU architecture.
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 will provide a default value for RISC-V when that is added, and it
makes sense to put this option next to the other DRAM layout options.
Signed-off-by: Samuel Holland <samuel@sholland.org>
This provides a default value for RISC-V when that is added, and it
makes sense to put this option next to the other DRAM layout options.
While at it, provide sensible values for platforms with less DRAM.
Signed-off-by: Samuel Holland <samuel@sholland.org>
This provides a default value for RISC-V when that is added, and it
makes sense to put this option next to the other DRAM layout options.
While at it, provide sensible values for platforms with less DRAM.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Update this option to be based on SUNXI_MINIMUM_DRAM_MB. This corrects
the value used on V3s, which previously was the MACH_SUN8I default, and
so relied on addresses wrapping modulo the DRAM size.
Signed-off-by: Samuel Holland <samuel@sholland.org>
This option affects the ABI between SPL/U-Boot and U-Boot/scripts, so it
should not normally be changed by the user.
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>
While R40 puts the EMAC syscon register at a different address from
other variants, the relevant portion of the register's layout is the
same. Factor out the register offset so the same code can be shared
by all variants. This matches what the Linux driver does.
This change provides two benefits beyond the simplification:
- R40 boards now respect the RX delays from the devicetree
- This resolves a warning on architectures where readl/writel
expect the address to have a pointer type, not phys_addr_t.
Series-to: sunxi
Cover-letter:
net: sun8i-emac: Allwinner D1 Support
D1 is a RISC-V SoC containing an EMAC compatible with the A64 EMAC.
However, there are a couple of issues with the driver preventing it
being built for RISC-V. These are resolved by patches 2-3. Patch 1 is
a general cleanup.
END
Signed-off-by: Samuel Holland <samuel@sholland.org>
Since the D1 CCU binding is defined, we can add support for its
gates/resets, following the pattern of the existing drivers.
Series-to: sunxi
Signed-off-by: Samuel Holland <samuel@sholland.org>
While not especially likely, it is plausible that someone wants to build
U-Boot without GPIO or UART support. Don't force building these drivers.
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>
- Fix and improve microchip's clock driver to allow sync'ing DTS with linux
- Improve the help message in "SBI_V02" Kconfig
- Improve DTS property "isa-string" parsing rule
Heinrich reports that on RISC-V unaligned access is emulated by OpenSBI
which is very slow. Performance wise it's better if we skip the calls
to u16_strdup() -- which in turn calls u16_strsize() and just allocate/copy the
memory directly. The access to dp.length may still be unaligned, but that's
way less than what u16_strsize() would do
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Use malloc() instead of calloc().
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Closing the files uses the EFI protocol and specifically it's .close
callback. This needs to be wrapped on an EFI_CALL()
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
UEFI specification requires pointers that are passed to protocol member
functions to be aligned. There's a u16_strdup in that function which
doesn't make sense otherwise Add a comment so no one removes it
accidentally
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The 'ret' variable must be initialized before use
in eficonfig_delete_invalid_boot_option().
Fixes: c416f1c0bc ("bootmenu: add removable media entries")
Addresses-Coverity: 376207 ("Uninitialized variables")
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Provide a description of the function's logic.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Goto for an immediately succeeding label is superfluous.
Fixes: 87d791423ac6 ("eficonfig: menu-driven addition of UEFI boot option")
Addresses-Coverity: 376202 ("Identical code for different branches")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
If the va_list we got handed over contains no protocols we must return
EFI_SUCCESS. However in that case the current code just returns
an unintialized value.
Fix that by setting the return value in the variable definition
Addresses-Coverity: CID 376195: ("Uninitialized variables (UNINIT)")
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
