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>
Implement the .get_function operation, so the gpio command can report
the current function. Since the GPIOF_FUNC (versus GPIOF_UNUSED) mux
values vary among the PMICs, report all non-GPIO mux values as UNKNOWN.
Signed-off-by: Samuel Holland <samuel@sholland.org>
There are three major variants of the AXP PMIC GPIO functionality (plus
PMICs with no GPIOs at all). Except for GPIO3 on the AXP209, which uses
a different register layout, it is straightforward to support all three
variants with a single driver. Do this, and in the process remove the
GPIO-related definitions from the PMIC-specific headers, and therefore
the dependency on AXP_PMIC_BUS.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Now that the PMIC driver implements the DM_PMIC uclass, those functions
can be used instead of the platform-specific "pmic_bus" functions.
Since the driver still uses the single set of register definitions from
axpXXX.h (as selected by AXPxxx_POWER), it still depends on one of those
choices, and therefore also AXP_PMIC_BUS.
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>
This is less confusing than half of the driver using "axp_gpio" and the
other half using "gpio_axp".
Signed-off-by: Samuel Holland <samuel@sholland.org>
These PMICs each have two GPIO pins, and are supported by the axp_gpio
driver. In order to convert the axp_gpio driver to probe using the
device tree, the corresponding device tree nodes must be present. Add
them, following the same binding as the AXP209 and AXP813.
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>
This adds a new PSCI implementation which communicates with SCP firmware
running on the AR100 using the SCPI protocol. This allows it to support
the full set of PSCI v1.1 features, including CPU idle states, system
suspend, and multiple reset methods.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Add the new option, function IDs, and prototypes for PSCI v1.1
implementations. In the process, fix some issues with the existing
definitions:
- Fix the incorrectly-named ARM_PSCI_0_2_FN64_SYSTEM_RESET2.
- Replace the deprecated "affinity_level" naming with "power_level".
Signed-off-by: Samuel Holland <samuel@sholland.org>
Now that issues with the BROM have been sorted out, we can implement
PSCI system suspend on H3 by delegating to SCP firmware. Let's start by
including the firmware in the FIT image and starting the coprocessor if
valid firmware is loaded.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Due to a bug in the H3 SoC, where the CPU 0 hotplug flag cannot be
written, resuming CPU 0 requires using the "Super Standby" code path in
the BROM instead of the hotplug path. This path requires jumping to an
eGON image in SRAM.
Add support to the build system to generate this eGON image and include
it in the FIT, and add code to direct the BROM to its location in SRAM.
Since the Super Standby code path in the BROM initializes the CPU and
AHB1 clocks to 24 MHz, those registers need to be restored after control
passes back to U-Boot. Furthermore, because the BROM lowers the AHB1
clock divider to /1 before switching to the lower-frequency parent,
PLL_PERIPH0 must be bypassed to prevent AHB1 from temporarily running at
600 MHz. Otherwise, this locks up the SoC.
Signed-off-by: Samuel Holland <samuel@sholland.org>
The struct is only used to overlay the MMIO region, so the behavior is
the same. This obsoletes the Kconfig option for the number of ports.
Series-to: Marek Vasut <marex@denx.de> (maintainer:USB)
Series-to: u-boot@lists.denx.de (open list)
Signed-off-by: Samuel Holland <samuel@sholland.org>
The code for these two options depends on having the FIT loadables
recorded in the FDT. Thus, these options require the full version of
the SPL_LOAD_FIT code.
Series-to: u-boot@lists.denx.de
Series-cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
With one exception (sun9i), all sunxi SoCs released to date use variants
of the same USB PHY. Instead of requiring each new SoC to duplicate the
PHY driver selection, enable it by default.
Series-to: Andre Przywara <andre.przywara@arm.com>
Series-to: Jagan Teki <jagan@amarulasolutions.com>
Signed-off-by: Samuel Holland <samuel@sholland.org>
This more closely matches the U-Boot driver to the Linux version.
Series-to: sunxi
Cover-letter:
mtd: nand: sunxi: Convert to devicetree and the driver model
This series converts the sunxi NAND driver to get its resources (clocks,
resets, pins) from the devicetree, and probe using the driver model.
In addition to the immediate cleanup, this allows backporting more
patches (bugfixes, newer SoC support) from the Linux driver.
END
Signed-off-by: Samuel Holland <samuel@sholland.org>
It is possible to use host-side USB with externally-provided VBUS. For
example, some USB OTG cables have an extra power input which powers
both the board and the USB peripheral.
To support this setup, skip enabling the VBUS switch/regulator if VBUS
voltage is already present. This behavior matches the Linux PHY driver.
Signed-off-by: Samuel Holland <samuel@sholland.org>
TOC1 is an container format used by Allwinner's boot0 that can hold
multiple images. It supports encryption and signatures, but that
functionality is not implemented, only the basic "non-secure" subset.
A config file is used to provide the list of data files to include. Its
path is passed as the argument to "-d". It contains sections of the
following form:
[name]
file = /path/to/file
addr = 0x12345678
Specific well-known names, such as "dtb", "opensbi", and "u-boot", are
used by the bootloader to distinguish the items inside the image.
Cover-letter:
tools: mkimage: Add Allwinner TOC1 support
The SPL port for the Allwinner D1 RISC-V SoC will probably take a while
longer than porting U-Boot proper, as none of the relevant drivers are
set up for DM in SPL. In the meantime, we are using[1][2] a fork[3] of
Allwinner's boot0 loader, which they also call "spl" in their BSP. boot0
uses this TOC1 image format.
The vendor tools for generating TOC1 images require a binary config file
generated by their FEX compiler. Instead of trying to support that, I
made up a simple human-readable config file format. I didn't see any
existing platform-agnostic parser for multi-image containers in mkimage.
I am sending this as RFC because it is only of temporary/limited use.
It only works with one specific fork of boot0 which was modified to
"behave" (the the original vendor version monkey-patches a custom header
inside the U-Boot image during boot). So it will be obsolete once U-Boot
SPL is ported. And it is Yet Another Image Format. On the other hand, it
does work, and it is currently being used.
[1]: https://linux-sunxi.org/Allwinner_Nezha#U-Boot
[2]: https://fedoraproject.org/wiki/Architectures/RISC-V/Allwinner
[3]: https://github.com/smaeul/sun20i_d1_spl
END
Series-prefix: RFC
Series-to: sunxi
Signed-off-by: Samuel Holland <samuel@sholland.org>
Clocks, resets, and pinmuxes are now handled by the driver model, so the
only thing the "board" code needs to do is load the driver. This matches
the pattern used by other DM raw NAND drivers (there is no NAND uclass).
The actual board code is now only needed in SPL.
Signed-off-by: Samuel Holland <samuel@sholland.org>
As a first step toward converting this driver to the driver model, use
the ofnode abstraction to replace direct references to the FDT blob.
Using ofnode_read_u32_index removes an extra pair of loops and makes the
allwinner,rb property optional, matching the devicetree binding.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Each chip is required to have a unique CS number ("reg" property) in the
range 0-7, so there is no need to separately count the number of chips.
Signed-off-by: Samuel Holland <samuel@sholland.org>
NAND is always at function 2 on port C.
Pin lists and mux values were taken from the Linux drivers.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Currently NAND clock setup is done in board code, both in SPL and in
U-Boot proper. Add the NAND clocks/resets here so they can be used by
the "full" NAND driver once it is converted to the driver model.
The bit locations are copied from the Linux CCU drivers.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Do not try to send an SGI from CPU 0 to itself. Since FIQs are masked
when entering monitor mode, this will hang. Plus, CPU 0 cannot fully
power itself off anyway. Instead, have it turn FIQs back on and continue
servicing SGIs from other cores.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Now that Crust (SCP firmware) has support for H3, we need a FIT image to
load it. H3 also needs to load a SoC-specific eGon blob to support CPU 0
hotplug. Let's first enable FIT support before adding extra firmware.
Update the binman description to work on either 32-bit or 64-bit SoCs:
- Make BL31 optional, since it is not used on 32-bit SoCs (though BL32
may be used in the future).
- Explicitly set the minimum offset of the FIT to 32 KiB, since SPL on
some boards is still only 24 KiB large even with FIT support enabled.
CONFIG_SPL_PAD_TO cannot be used because it is not defined for H616.
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 simplicity, enable that option everywhere.
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.
There was no existing binman entry property that put the FIT at the
right offset. The minimum offset is 32k, but this matches neither the
SPL size (which is no more than 24k on some SoCs) nor the FIT alignment
(which is 512 bytes in practice due to SPL size constraints). So instead
of adding a new property, I fixed what is arguably a bug in the offset
property -- though this strategy will not work if someone is
intentionally creating overlapping entries.
END
Series-to: sunxi
Series-to: sjg
Signed-off-by: Samuel Holland <samuel@sholland.org>
Currently, if the "offset" property is given for an entry, the section's
running offset is completely ignored. This causes entries to overlap if
the provided offset is less than the size of the entries earlier in the
section. Avoid the overlap by only using the provided offset when it is
greater than the running offset.
The motivation for this change is the rule used by SPL to find U-Boot on
sunxi boards: U-Boot starts 32 KiB after the start of SPL, unless SPL is
larger than 32 KiB, in which case U-Boot immediately follows SPL.
Signed-off-by: Samuel Holland <samuel@sholland.org>
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>
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>
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>
Now that this functionality is modeled using the device tree and
regulator uclass, the named GPIO is not referenced anywhere. Remove
it, along with the rest of the support for AXP virtual GPIOs.
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>
