| Age | Commit message (Collapse) | Author |
|---|
|
Fix a simple spelling mistake in a comment.
Reviewed-by: Dragan Simic <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
Signed-off-by: Christopher Obbard <[email protected]>
|
|
The STM32_RST line is routed to the ATtiny microcontroller
PA0/RESET/UPDI pin. By driving the PX30 SoC pin as GPIO output high, we
prevent external UPDI to be used for flashing without first putting this
pin as GPIO input, an extra step we could avoid in userspace.
There's an external hardware pull-up strong enough to keep the STM32_RST
state high on ATtiny side but weak enough it can be overridden by
external UPDI. This also means it is safe to use for the STM32 variant,
where STM32_RST line will be in the same state as if output high was
used.
The Q7 standard specifies that MFG_NC1 and MFG_NC2 (used for UPDI for
Ringneck) pins should neither be driven by the carrierboard, nor have
pull-up or pull-down resistors. This means this commit is safe to use
regardless of the carrierboard this module would be connected to
(provided it follows the Q7 standard).
Fixes: 6acdd63e8771 ("rockchip: ringneck-px30: always reset STM32 companion controller on boot")
Cc: Quentin Schulz <[email protected]>
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
Add missing boot source id <-> device tree node path mapping for SPI NOR
flash on PX30, RK3288, RK3308, RK3368 and RV1126.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Dragan Simic <[email protected]>
|
|
Rockchip BROM writes a boot source id at CFG_IRAM_BASE + 0x10, this id
indicates from what storage media TPL/SPL was loaded from.
SPL uses this id to determine what device "same-as-spl" represent when
determining from where FIT should be loaded. This works as long as the
boot_devices array contain a matching id <-> node path entry.
However, SPL typically load a small part of TF-A into SRAM and on RK3399
this overwrites the CFG_IRAM_BASE + 0x10 addr used for boot source id.
For affected devices the u-boot,spl-boot-device would not be set when
booting from SPI flash and the flash@0 node was not explicitly listed
in the u-boot,spl-boot-order prop.
Here boot source id is 3 before FIT images is loaded, and 0 after:
U-Boot SPL 2024.04-rc4 (Mar 15 2024 - 17:26:19 +0000)
board_spl_was_booted_from: brom_bootdevice_id 3 maps to '/spi@ff1d0000/flash@0'
Trying to boot from SPI
## Checking hash(es) for config config-1 ... OK
## Checking hash(es) for Image atf-1 ... sha256+ OK
## Checking hash(es) for Image u-boot ... sha256+ OK
## Checking hash(es) for Image fdt-1 ... sha256+ OK
## Checking hash(es) for Image atf-2 ... sha256+ OK
## Checking hash(es) for Image atf-3 ... sha256+ OK
board_spl_was_booted_from: failed to resolve brom_bootdevice_id 0
spl_decode_boot_device: could not find udevice for /mmc@fe330000
spl_decode_boot_device: could not find udevice for /mmc@fe320000
spl_perform_fixups: could not map boot_device to ofpath: -19
Use a static brom_bootsource_id_cache to save the boot source id after
an initial read from SRAM to fix this, this allow spl_perform_fixups()
to resolve correct boot source path for "same-as-spl" after SPL have
loaded TF-A related FIT images into memory.
With this the spl-boot-device prop can correctly be resolved to the
SPI flash node in the control FDT:
=> fdt addr ${fdtcontroladdr}
Working FDT set to f1ee6710
=> fdt list /chosen
chosen {
u-boot,spl-boot-device = "/spi@ff1d0000/flash@0";
stdout-path = "serial2:1500000n8";
u-boot,spl-boot-order = "same-as-spl", "/mmc@fe330000", "/mmc@fe320000";
};
Fixes: d57e16c7e712 ("rockchip: find U-boot proper boot device by inverting the logic that sets it")
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
Reviewed-by: Dragan Simic <[email protected]>
|
|
Add more bootsource id:
1. BROM_BOOTSOURCE_UNKNOWN
2. BROM_BOOTSOURCE_I2C
3. BROM_BOOTSOURCE_SPI
Signed-off-by: Jason Zhu <[email protected]>
[[email protected]: Update commit message]
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Dragan Simic <[email protected]>
|
|
Currently fetching files bigger that cause a data transfer greater than
U16_MAX fails.
The reason is that the specification defines the datalength register
as a 16 bit wide register, but in u-boot it is used as if it is an
32 bit register. Therefore values greater than U16_MAX cause an
infinite loop inside u-boot. U-boot expects to get more data from
interface/hardware then it will ever get and therefore inifintely waits
for more data that will never come.
Signed-off-by: Maximilian Brune <[email protected]>
Cc: Peng Fan <[email protected]>
Cc: Jaehoon Chung <[email protected]>
Reviewed-by: Jaehoon Chung <[email protected]>
|
|
According to the SD Host Controller Simplified Specification v4.20,
the multiplier value M is one more than the Clock Multiplier field.
Copied code from Linux project. drivers/mmc/host/sdhci.c line 4405
Signed-off-by: cmachida <[email protected]>
Reviewed-by: Jaehoon Chung <[email protected]>
Reviewed-by: Sean Anderson <[email protected]>
|
|
The linux commit f722e650d965 ("mmc: core: add support for disabling
HS400 mode via DT") added support for a no-mmc-hs400 prop.
Add support for the no-mmc-hs400 prop to disable HS400 host caps.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Dragan Simic <[email protected]>
Reviewed-by: Jaehoon Chung <[email protected]>
|
|
eMMC nodes in linux device tree files typically only contain a mmc-hs400
prop to signal support for both HS400 and HS200. However, U-Boot require
an explicit mmc-hs200 prop to signal support for the HS200 mode.
Fix this by follow linux and imply HS200 cap when HS400 cap is signaled
using a mmc-hs400 prop.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Dragan Simic <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
Reviewed-by: Jaehoon Chung <[email protected]>
|
|
Some arm64 platforms may include SDIO host controllers that
only support 32-bit ADMA. While the Linux kernel detects which
size is supported and adjusts the descriptor size used dynamically,
the previous u-boot implementation statically selected between the
two depending on whether DMA_ADDR_T_64BIT was defined. Because the
static selection is already in place and effective for most platforms,
this patch logically separates "64 bit addresses are used for DMA on
this platform" and "64 bit addresses are used by the SDIO host
controller for ADMA" in order to support the small number of platforms
where these statements are not equivalent.
Using 32 bits is opt-in and existing 64 bit platforms should be
unaffected by this change.
Co-developed-by: Nathan Barrett-Morrison <[email protected]>
Signed-off-by: Nathan Barrett-Morrison <[email protected]>
Co-developed-by: Ian Roberts <[email protected]>
Signed-off-by: Ian Roberts <[email protected]>
Signed-off-by: Greg Malysa <[email protected]>
Reviewed-by: Jaehoon Chung <[email protected]>
|
|
Change ADMA_TABLE_NO_ENTRIES to round the division up to fully
contain CONFIG_SYS_MMC_MAX_BLK_COUNT, fixing potential buffer overflow
of the ADMA descriptor table.
sdhci_prepare_adma_table() expecitily states it does _not_ check for
overflow as the descriptor table size is dependent on
CONFIG_SYS_MMC_MAX_BLK_COUNT. However, the ADMA_TABLE_NO_ENTRIES
calculation does not round up the divison, so with the current u-boot
defaults:
max_mmc_transfer = (CONFIG_SYS_MMC_MAX_BLK_COUNT * MMC_MAX_BLOCK_LEN) =
65535 * 512 = 33553920 bytes.
ADMA_TABLE_NO_ENTRIES = max_mmc_transfer / ADMA_MAX_LEN =
33553920 / 65532, which does not divide cleanly.
actual_max_transfer = ADMA_TABLE_NO_ENTRIES * ADMA_MAX_LEN = 512 *
65532 = 33552384, which is smaller than max_mmc_transfer.
This can cause sdhci_prepare_adma_table() to write one extra
descriptor, overflowing the table when a transaction larger than
actual_max_transfer is issued.
Co-developed-by: Nathan Barrett-Morrison <[email protected]>
Signed-off-by: Nathan Barrett-Morrison <[email protected]>
Signed-off-by: Greg Malysa <[email protected]>
Signed-off-by: Ian Roberts <[email protected]>
Reviewed-by: Jaehoon Chung <[email protected]>
|
|
Add this hook so that it can be overridden with driver specific
implementations. We also let the original sdhci_adma_write_desc()
accept &desc so that the function can set its new value. Then export
the function so that it could be reused by driver's specific
implementations.
The above is a port of Linux kernel commit 54552e4948cbf
In addition, allow drivers to allocate their own ADMA descriptor
tables if additional space is required.
Finally, fix the assignment of adma_addr to fix compiler warning
on 64-bit platforms that still use 32-bit DMA addressing.
Co-developed-by: Nathan Barrett-Morrison <[email protected]>
Signed-off-by: Nathan Barrett-Morrison <[email protected]>
Co-developed-by: Greg Malysa <[email protected]>
Signed-off-by: Greg Malysa <[email protected]>
Signed-off-by: Ian Roberts <[email protected]>
|
|
Add orphaned TEE/OP-TEE-related files to TEE subsystem entry in
MAINTAINERS. This includes:
- optee_rpmb cmd and test for it
- Misc. OP-TEE tests
- OP-TEE SCMI agent implementation
- Documentation, including device tree bindings
Signed-off-by: Igor Opaniuk <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
Add additional check for buffer size when reading out persistent
storage value and provide back actual value size.
Signed-off-by: Igor Opaniuk <[email protected]>
Reviewed-by: Oleksandr Suvorov <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-fsl-qoriq
- move to OF_UPSTREAM for sl28
|
|
Support is added for 5 new Qualcomm SoCs:
* QCM2290 and SM6115 are low and mid range SoCs used on the RB1 and RB2
respectively. SM6115 is also used in some mid-range smartphones/tablets.
Initial support includes buttons and USB (host and gadget).
* SM8250 is a flagship SoC from 2020 used on the RB5, as well as many flagship
smartphones. The board can boot to a U-Boot prompt, but is missing regulators
necessary for USB support.
* SM8550, and SM8650 are flagship mobile SoCs from 2023 and 2024
respectively. Found on many high end smartphones.
In addition:
* Support is added for the Schneider HMIBSC board.
* mach-snapdragon switches to OF_UPSTREAM
* IPQ40xx gets several regressions fixed and some overall cleanup.
* The MSM serial driver gains the ability to generate the bit-clock
automatically, no longer relying on a custom DT property.
* The Qualcomm SMMU driver gets a generic compatible (so per-SoC compatibles
don't need to be added).
* Support for the GENI I2C controller is added.
* The qcom SPMI driver has SPMI v5 support fixed, and v7 support added.
* The qcom sdhci driver gets some fixes for SDCC v5 support.
* SDM845 gains sdcard support
* Support is added for the Synopsys eUSB2 PHY driver (used on SM8550 and SM8650)
* SYS_INIT_SP_BSS_OFFSET is set to 1.5M to give us more space for FDTs.
* RB2 gets a work-around to fix the USB dr_mode property before booting Linux.
|
|
Use the new device devicetree files in dts/upstream/ and delete the old
ones. Still keep the -u-boot.dtsi with all u-boot specifics around.
There is one catch and that is fsl-ls1028a-kontron-sl28-var3.dts which
is not available upstream (yet!). For now, the base dts is used for this
variant as this only differ in the compatible and the (human readable)
model name.
Signed-off-by: Michael Walle <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Enable the GENI I2C driver in the default Qualcomm defconfig.
Reviewed-by: Caleb Connolly <[email protected]>
Signed-off-by: Neil Armstrong <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
Add Support for the Qualcomm Generic Interface (GENI) I2C interface
found on newer Qualcomm SoCs.
The Generic Interface (GENI) is a firmware based Qualcomm Universal
Peripherals (QUP) Serial Engine (SE) Wrapper which can support multiple
bus protocols depending on the firmware type loaded at early boot time
based on system configuration.
It also supports the "I2C Master Hub" which is a single function Wrapper
that only FIFO mode I2C.
It replaces the fixed-function QUP Wrapper found on older SoCs.
The geni-se.h containing the generic GENI Serial Engine registers defines
is imported from Linux.
Only FIFO mode is implemented, neither SE DMA nor GPI DMA are implemented.
Signed-off-by: Neil Armstrong <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
EFI initialisation fails without this, and with proper SMBIOS v3 support
in (and automatic generation of useful tables) there's no reason for us
not to do this on qcom platforms.
Signed-off-by: Caleb Connolly <[email protected]>
|
|
Defining this as 0 results in bootm causing a null pointer exception...
Define it at a safe default which is valid RAM on most qcom boards.
Signed-off-by: Caleb Connolly <[email protected]>
|
|
Use our new ft_board_setup().
Signed-off-by: Caleb Connolly <[email protected]>
|
|
Some Qualcomm boards have only one USB controller which is muxed between
the type-c port and an internal USB hub for type-A and ethernet. We
modify the DT for these to force them to host mode in U-Boot. However in
Linux DRD role switching is supported (required, even). Use
ft_board_setup() to adjust the dr_mode property for these boards.
While we're here, define pr_fmt for this file so we can more easily
identify log messages.
Signed-off-by: Caleb Connolly <[email protected]>
|
|
Add a fixup to force dr_mode to host for U-Boot.
Signed-off-by: Caleb Connolly <[email protected]>
|
|
There is a clock associated with this phy, but it's always from the
rpmhcc and isn't actually needed for the hardware to work.
Drop all the clock handling from the driver.
Signed-off-by: Caleb Connolly <[email protected]>
|
|
With the exception of SDM845, most other Qualcomm SoCs have the Qualcomm
specific (but not SoC) specific SMMU compatible string. Add it here so
we can match those without having to add individual SoCs to the list
here.
Signed-off-by: Caleb Connolly <[email protected]>
|
|
This is used for the volume keys on some SM8150/SM8250 devices.
Signed-off-by: Caleb Connolly <[email protected]>
|
|
As with some other modern PMICs, writing to the GPIOs seems to make the
device reset.
Signed-off-by: Caleb Connolly <[email protected]>
|
|
Add the defines and support for SPMI arbiters version 7,
which can handle up to 1024 peripherals, and can also drive
a secondary bus which is not implemented yet.
Signed-off-by: Neil Armstrong <[email protected]>
Acked-by: Caleb Connolly <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
The cnfg registers provides the owner id for each peripheral,
so we can use this id to check if we're allowed to write register
to each peripherals.
Since the v5 can handle more peripherals, add the max_channels to
scan more starting from version 5, make the channel_map store
32bit values and introduce the SPMI_CHANNEL_READ_ONLY flag to
mark a peripheral as read-only.
Signed-off-by: Neil Armstrong <[email protected]>
Acked-by: Caleb Connolly <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
Since version 2, the cmd format has changed, takes helpers
from Linux driver and use a switch/case to handle all
versions in msm_spmi_write/read() command.
Signed-off-by: Neil Armstrong <[email protected]>
Acked-by: Caleb Connolly <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
Properly use ch_offset in msm_spmi_write() reg access.
Fixes: f5a2d6b4b03 ("spmi: msm: add arbiter version 5 support")
Signed-off-by: Neil Armstrong <[email protected]>
Acked-by: Caleb Connolly <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
Support for Schneider Electric HMIBSC. Features:
- Qualcomm Snapdragon 410C SoC - APQ8016 (4xCortex A53, Adreno 306)
- 2GiB RAM
- 64GiB eMMC, SD slot
- WiFi and Bluetooth
- 2x Host, 1x Device USB port
- HDMI
- Discrete TPM2 chip over SPI
Features enabled in U-Boot:
- RAUC updates
- Environment protection
- USB based ethernet adaptors
Signed-off-by: Sumit Garg <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
Schneider HMIBSC board dts has already been reviewed upstream on the
linux-arm-msm mailing list. So once it comes through the Linux kernel
release cycle into the U-Boot dts/upstream subtree, a switch to
OF_UPSTREAM can be made. For the time being maintain the U-Boot copy.
Link: https://lore.kernel.org/linux-kernel/[email protected]/
Signed-off-by: Sumit Garg <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
Add GPIO pinctrl function to enable driving GPIO pins as output low or
high.
Signed-off-by: Sumit Garg <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
Add support for driving the GPIO pins as output low or high.
Signed-off-by: Sumit Garg <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
SE HMIBSC board debug console requires RS232 flow control, so enable
corresponding support if RS232 gpios are present.
Reviewed-by: Caleb Connolly <[email protected]>
Signed-off-by: Sumit Garg <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
SE HMIBSC board uses UART1 as the main debug console, so add
corresponding clocks and pinmux support. Along with that update
instructions to enable clocks for debug UART support.
Reviewed-by: Caleb Connolly <[email protected]>
Signed-off-by: Sumit Garg <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
Enabling LINUX_KERNEL_IMAGE_HEADER by default doesn't allow
ENABLE_ARM_SOC_BOOT0_HOOK to work properly on db410c when U-Boot is
loaded as a first stage bootloader. It leads to secondary CPUs bringup
failure and later causing the Linux kernel to freeze.
So fix it via selectively enabling LINUX_KERNEL_IMAGE_HEADER where it's
actually required.
Fixes: 059d526af312 ("mach-snapdragon: generalise board support")
Reviewed-by: Caleb Connolly <[email protected]>
Signed-off-by: Sumit Garg <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
Currently, IPQ4019 pinctrl driver supports only a very limited number of
pin functions and is not fully DT compatible with Linux pinctrl nodes.
IPQ40xx SoC-s sometimes use different pin function numbers for the same
function depending on the pin number, so for example I2C0 on GPIO58 uses
function number 3 while on GPIO59 it uses function number 2.
So, in order to make the driver compatible with upstream DTS to avoid the
need to patch the pinctrl nodes in U-Boot and support all of the missing
pin functions lets rework the driver based on upstream Linux IPQ4019
pinctrl driver and the pending SM8150 U-Boot pinctrl driver which also uses
different function numbers pased on the exact pin number.
Signed-off-by: Robert Marko <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
If compiled with logging and debug UART support, the following is printed:
serial_msm serial@78af000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19
This is due to the fact that IPQ4019 pinctrl driver is not available prior
to relocation and thus MSM serial will fail probing as pinctrl provider is
not available.
So, lets enable DM_FLAG_PRE_RELOC for IPQ4019 pinctrl to fix this.
Signed-off-by: Robert Marko <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
We want to use OF_UPSTREAM on IPQ40XX as its well supported upstream, so
as a preparation update pinctrl driver to look for the upstream pin format.
Signed-off-by: Robert Marko <[email protected]>
Reviewed-by: Caleb Connolly <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
Pinctrl driver was refactored and moved, but the required header that
it depends on was not included.
Fixes: 24d2908e987a ("pinctrl: qcom: move ipq4019 driver from mach-ipq40xx")
Signed-off-by: Robert Marko <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
IPQ4019 pinctrl driver was moved to the dedicated Qualcomm pinctrl
directory, but the KConfig depends on ARCH_SNAPDRAGON only and thus
PINCTRL_QCOM_IPQ4019 cannot be selected when ARCH_IPQ40XX is used.
Fixes: 24d2908e987a ("pinctrl: qcom: move ipq4019 driver from mach-ipq40xx")
Signed-off-by: Robert Marko <[email protected]>
Reviewed-by: Caleb Connolly <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
IPQ40xx SoC-s dont have proper SMEM support like more modern Qualcomm
SoC-s so there is no point in selecting the required drivers.
Signed-off-by: Robert Marko <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
Give us lots of room for the appended FDT.
Reviewed-by: Neil Armstrong <[email protected]>
Reviewed-by: Sumit Garg <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
These files are all identical (or older) than those in dts/upstream.
Drop them as we now use upstream DTS files with OF_UPSTREAM.
Reviewed-by: Neil Armstrong <[email protected]>
Reviewed-by: Sumit Garg <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
Switch to using upstream DT from dts/upstream.
Reviewed-by: Neil Armstrong <[email protected]>
Reviewed-by: Sumit Garg <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
The driver currently requires the bit clock divider be hardcoded in
devicetree (or use the hardcoded default from apq8016).
The bit clock divider is used to derive the baud rate from the core
clock:
baudrate = clk_rate / csr_div
clk_rate is the actual programmed core clock rate which is returned by
clk_set_rate(), and this UART driver only supports a baudrate of 115200.
We can therefore determine the appropriate value for UARTDM_CSR by
iterating over the possible values and finding the one where the
equation above holds true for a baudrate of 115200.
Implement this logic and drop the non-standard DT bindings for this
driver.
Tested on dragonboard410c.
Tested-by: Robert Marko <[email protected]>
Signed-off-by: Caleb Connolly <[email protected]>
|
|
clk_set_rate() should return the clock rate that was set. The IPQ4019
clock driver doesn't set any rates yet but it should still return the
expected value so that drivers can work properly.
For a baud rate of 115200 with an expected bit clock divisor of 16, the
clock rate should be 1843200 so return that frequency.
Signed-off-by: Caleb Connolly <[email protected]>
|
