Tom Rini [Sat, 14 Dec 2024 15:34:27 +0000 (09:34 -0600)]
Merge patch series "Hyperflash Boot fixes for J7200/J721E"
Anurag Dutta <a-dutta@ti.com> says:
Hi All,
In u-boot, hbmc is broken and has been removed from j7200
configs. This series re-enables the hbmc driver and introduces a series
of hyperflash boot fixes. At present, in u-boot, the parent device (fss)
gets registered as a syscon device. This is done because the MMIO
mux driver in u-boot did not support the mux functionality when the
parent device is not a syscon. In this series, we make relevant changes
in the hbmc driver as well as dts' so that we can use the reg-mux driver for
selecting the appropriate state of the mux.
Anurag Dutta [Fri, 29 Nov 2024 11:31:36 +0000 (17:01 +0530)]
mtd: Kconfig: Change HBMC driver's dependency to MULTIPLEXER and MUX_MMIO
The HBMC_AM654 driver was dependent on SYSCON because syscon APIs were
being used to select the multiplexer state. Change the dependency to
MULTIPLEXER and MUX_MMIO because mux APIs are now being used to
select mux state.
Vaishnav Achath [Fri, 29 Nov 2024 11:31:35 +0000 (17:01 +0530)]
configs: j7200_evm_*_defconfig: Add configs for Hyperflash boot
Kernel commit dbb124cf6888 ("configs: j7200: Remove HBMC_AM654
config") removed the HBMC_AM654 config because hbmc was broken
in u-boot. Hence, add the missing configs necessary to re-enable
Hyperflash boot.
include: configs: j721e_evm: Increase memory offset for tiboot3.bin in HyperFlash
The size of J7200 tiboot3.bin is 516KB but the memory reserved for it in
HyperFlash was 512KB. This led to overlap of tiboot3.bin over tispl.bin
region and break in HyperFlash boot mode.
Therefore, fix this by increasing the memory allocated for tiboot3.bin
to 1MB for J7200.
Vaishnav Achath [Fri, 29 Nov 2024 11:31:33 +0000 (17:01 +0530)]
configs: j721e_evm_*_defconfig: Add configs for Hyperflash boot
Kernel commit 5b2671594b80 ("configs: j721e: Remove HBMC_AM654
config") removed the HBMC_AM654 config because hbmc was broken
in u-boot. Hence, add the missing configs necessary to re-enable
Hyperflash boot.
Anurag Dutta [Fri, 29 Nov 2024 11:31:30 +0000 (17:01 +0530)]
mtd: HBMC-AM654: Changed syscon API to mux APIs
The syscon APIs were used for selecting the state of the mux
device because the mmio-mux driver in u-boot did not support
the mux functionality when the parent device is not a syscon.
Change to mux APIs which utilizes the reg-mux driver to select the
state of the multiplexer.
Tom Rini [Sat, 14 Dec 2024 15:33:03 +0000 (09:33 -0600)]
Merge patch series "UART support for higher baudrate"
Gokul Praveen <g-praveen@ti.com> says:
The OMAP specific UART driver is changed from a generic implementation of
certain ops functions to an OMAP specific implementation of it to add
support for higher baudrates for OMAP devices.
Hence to support the above change, static functionality of ops functions
in generic ns16550 UART U-Boot driver is removed and also migrated certain
macros to its header file for usage in device-specific drivers.
Gokul Praveen [Tue, 26 Nov 2024 10:51:31 +0000 (16:21 +0530)]
drivers: serial: serial_omap: Fix TI OMAP UART U-Boot driver to support higher baudrates
Move to OMAP specific implementation of certain ops functions as the UART
prints on the serial console fail for baudrates greater than 460800.
The MDR1 register is responsible for determining the speed mode at which
the UART should operate for OMAP specific devices. The baud divisor is used
to set the UART_DLL register which is used for generation of the baud
clock in the baud rate generator. The implementation logic is similar to
how it is implemented in omap_8250_get_divisor function of 8250_omap UART
linux driver.
Signed-off-by: Gokul Praveen <g-praveen@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Tom Rini [Fri, 13 Dec 2024 23:30:27 +0000 (17:30 -0600)]
Merge patch series "Add phyCORE AM62Ax"
Garrett Giordano <ggiordano@phytec.com> says:
This patch set adds the phyCORE AM62Ax board support and documenation to
u-boot.
The phyCORE-AM62Ax is a SoM (System on Module) featuring TI's AM62Ax SoC. It can
be used in combination with different carrier boards. This module can come
with different sizes and models for DDR, eMMC, SPI NOR Flash and various SoCs
from the AM62x family.
A development Kit, called phyBOARD-Lyra is used as a carrier board reference
design around the AM62x SoM.
This series depends on the following two patches:
- [PATCH v2] arm: mach-k3: am62a7: Provide a way to obtain boot device for non SPL
https://lists.denx.de/pipermail/u-boot/2024-October/570156.html
- [PATCH] board: phytec: common: Introduce CONFIG_PHYTEC_K3_DDR_PATCH
https://lists.denx.de/pipermail/u-boot/2024-November/571543.html
Garrett Giordano [Thu, 31 Oct 2024 16:21:03 +0000 (09:21 -0700)]
arm: mach-k3: am62a7: Provide a way to obtain boot device for non SPLs
Introduce get_boot_device() to obtain the booting device. Make it also
available for non SPL builds so u-boot can also know the device it
is booting from.
Signed-off-by: Garrett Giordano <ggiordano@phytec.com> Reviewed-by: Bryan Brattlof <bb@ti.com> Reviewed-by: Andrew Davis <afd@ti.com>
The module pid4 currently corresponds to the index of the toradex_module
array. If a new pid4 is introduced that does not follow the sequence of
the previous entries, it will create a gap in the array.
To address this, embed pid4 within the toradex_som structure and
implement a function to retrieve the index corresponding to pid4.
Signed-off-by: Vitor Soares <vitor.soares@toradex.com> Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Wadim Egorov [Wed, 27 Nov 2024 12:17:35 +0000 (13:17 +0100)]
board: phytec: k3: Add EFI capsule update support
Implement EFI capsule update functionality for PHYTEC K3-based SoMs.
These SoMs feature various flash device options, including eMMC,
OSPI NOR, and uSD card at the board level.
This update provides the necessary logic to enable EFI capsule updates
across all three flash devices, ensuring flexible and robust firmware
upgrade capabilities.
The GUID is dynamically generated for the board, to get it:
Tom Rini [Fri, 13 Dec 2024 20:14:50 +0000 (14:14 -0600)]
Merge patch series "AM62A DWC3: Add support for USB DFU boot in OTG mode"
Siddharth Vadapalli <s-vadapalli@ti.com> says:
Hello,
This series adds support for USB DFU boot on TI's AM62A SoC which has
two instances of DWC3 USB Controllers namely USB0 and USB1. The USB0
instance of the USB Controller supports USB DFU boot:
ROM => tiboot3.bin => tispl.bin => u-boot.img
USB DFU Boot requires the USB Controller to be configured for Gadget
mode of operation. Since the USB0 instance of the DWC3 USB Controller
supports both Host and Gadget modes of operation via the Type-C interface
on the AM62A7-SK board, the device-tree specifies the "dr_mode" as "OTG".
However, there is currently no support for dynamically switching the "mode"
from Host to Gadget and vice-versa with the help of a state-machine.
The OTG mode is treated as a separate mode in itself rather than being
treated as an intermediate stage before assuming the Host/Gadget mode.
Due to this, USB DFU boot via the Type-C interface doesn't work as the
USB Controller hasn't been appropriately configured for Device/Gadget
mode of operation. One option is to change the device-tree to specify
"dr_mode" as "peripheral" and force the controller to assume the Device
role. This will imply that the U-Boot device-tree for AM62A diverges
from its Linux counterpart. Therefore, with the intent of keeping the
device-tree uniform across Linux and U-Boot, and at the same time, in
order to enable USB DFU boot in "OTG" mode with the DWC3 Controller,
the first patch in this series sets the "mode" on the basis of the
caller function, rather than using the "dr_mode" property in the
device-tree. There are only two callers of "dwc3_generic_probe()",
each of which clearly specify the expected mode of configuration.
This will enable both Host and Device mode of operation based on the
command executed by the user, thereby truly supporting "OTG"
functionality when the USB Controller supports it.
The second patch in this series adds USB DFU environment for AM62A,
enabling USB DFU Boot and USB DFU flash on AM62A.
In addition to the patches in this series, the following device-tree
changes will be required to test USB DFU on AM62A (bootph-all property
to be added to ensure that USB Controller is present at all stages
for DFU Boot):
https://gist.github.com/Siddharth-Vadapalli-at-TI/53ba02cb0ff4a09c47e920d08247065f
The above device-tree changes will be made to the Linux device-tree,
which shall ensure that the same shall be a part of U-Boot device-tree
eventually.
The USB DFU config fragments for AM62x have been used for enabling
USB DFU boot on AM62a as follows:
R5 => am62ax_evm_r5_defconfig + am62x_r5_usbdfu.config
A53 => am62ax_evm_a53_defconfig + am62x_a53_usbdfu.config
Logs validating USB DFU boot with this series:
https://gist.github.com/Siddharth-Vadapalli-at-TI/daa71da1b0e478a51afea42605fb2d2c
usb: dwc3-generic: set "mode" based on caller of dwc3_generic_probe()
There are only two callers of "dwc3_generic_probe()", namely:
1. dwc3_generic_peripheral_probe()
2. dwc3_generic_host_probe()
Currently, the "mode" is set based on the device-tree node of the
platform device. Also, the DWC3 core doesn't support updating the "mode"
dynamically at runtime if it is set to "OTG", i.e. "OTG" is treated as a
separate mode in itself, rather than being treated as a mode which should
eventually lead to "host"/"peripheral".
Given that the callers of "dwc3_generic_probe()" clarify the expected
"mode" of the USB Controller, use that "mode" instead of the one
specified in the device-tree. This shall allow the USB Controller to
function both as a "Host" and as a "Peripheral" when the "mode" is "otg"
in the device-tree, based on the caller of "dwc3_generic_probe()".
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Reviewed-by: Marek Vasut <marex@denx.de> Reviewed-by: Roger Quadros <rogerq@kernel.org>
Jayesh Choudhary [Tue, 26 Nov 2024 07:06:12 +0000 (12:36 +0530)]
arm: mach-k3: am62p: Add QoS support for DSS
Enable Quality of Service (QoS) blocks for Display SubSystem (DSS), by
servicing the DSS - DDR traffic from the Real-Time (RT) queue. This is
done by setting the DSS DMA orderID to greater than 7.
DDR intensive software applications can overwhelm the DSS's access to
the DDR because of their higher frequency DDR accesses. This can cause
flickering in display with certain applications running parallely if
the DSS traffic is being serviced through non-RT queue.
Jayesh Choudhary [Tue, 26 Nov 2024 07:06:11 +0000 (12:36 +0530)]
arm: mach-k3: j722s: Add QoS support for DSS
Enable Quality of Service (QoS) blocks for Display SubSystem (DSS), by
servicing the DSS - DDR traffic from the Real-Time (RT) queue. This is
done by setting the DSS DMA orderID to greater than 7.
The C7x and VPAC can overwhelm the DSS's access to the DDR because of
their higher frequency DDR accesses. This can cause flickering in
display with certain edgeAI models running parallely if the DSS traffic
is being serviced through non-RT queue.
Tom Rini [Thu, 12 Dec 2024 22:35:47 +0000 (16:35 -0600)]
Merge patch series "vbe: Series part E"
Simon Glass <sjg@chromium.org> says:
This includes various patches towards implementing the VBE abrec
bootmeth in U-Boot. It mostly focuses on SPL tweaks and adjusting what
fatures are available in VPL.
Simon Glass [Sat, 7 Dec 2024 17:24:05 +0000 (10:24 -0700)]
spl: Drop use of uintptr_t
U-Boot uses ulong for addresses. It is confusing to use uintptr_t in a
few places, since it makes people wonder if the types are compatible.
Change the few occurences in SPL to use ulong
Simon Glass [Sat, 7 Dec 2024 17:23:56 +0000 (10:23 -0700)]
boot: Allow FIT to fall back from best-match option
When the best-match feature fails to find something, use the provided
config name as a fallback. The allows SPL to select a suitable config
when best-match is enabled.
Sam Protsenko [Fri, 8 Mar 2024 00:04:32 +0000 (18:04 -0600)]
clk: Propagate clk_set_rate() if CLK_SET_PARENT_RATE present
Sometimes clocks provided to a consumer might not have .set_rate
operation (like gate or mux clocks), but have CLK_SET_PARENT_RATE flag
set. In that case it's usually possible to find a parent up the tree
which is capable of setting the rate (div, pll, etc). Implement a simple
lookup procedure for such cases, to traverse the clock tree until
.set_rate capable parent is found, and use that parent to actually
change the rate. The search will stop once the first .set_rate capable
clock is found, which is usually enough to handle most cases.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Sam Protsenko [Wed, 11 Dec 2024 02:17:02 +0000 (20:17 -0600)]
boot: fdt: Handle already reserved memory in boot_fdt_reserve_region()
The boot_fdt_add_mem_rsv_regions() function can be called twice, e.g.
first time during the board init (as a part of LMB init), and then when
booting the OS with 'booti' command:
That consequently leads to the attempt of reserving the same memory
areas (described in the 'reserved-memory' dts node) in LMB. The
lmb_add_region_flags() returns -EEXIST error code in such cases, but
boot_fdt_reserve_region() handles all negative error codes as a failure
to reserve fdt memory region, printing corresponding error messages,
which are essentially harmless, but misleading. For example, this is the
output of 'booti' command on E850-96 board:
The mentioned false positive error messages are observed starting with
commit 1d9aa4a283da ("lmb: Fix the allocation of overlapping memory
areas with !LMB_NONE"), which removes the check for the already added
memory regions in lmb_add_region_flags(), making it return -1 for
!LMB_NONE cases. Another commit 827dee587b75 ("fdt: lmb: add reserved
regions as no-overwrite") changes flags used for reserving memory in
boot_fdt_add_mem_rsv_regions() from LMB_NONE to LMB_NOOVERWRITE. So
together with the patch mentioned earlier, it makes
lmb_add_region_flags() return -1 when called from
boot_fdt_reserve_region().
Since then, the different patch was implemented, returning -EEXIST error
code in described cases, which is:
lmb: Return -EEXIST in lmb_add_region_flags() if region already added
Handle -EEXIST error code as a normal (successful) case in
lmb_reserve_flags() and don't print any messages.
Fixes: 1d9aa4a283da ("lmb: Fix the allocation of overlapping memory areas with !LMB_NONE") Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Michal Simek <michal.simek@amd.com>
Sam Protsenko [Wed, 11 Dec 2024 02:17:01 +0000 (20:17 -0600)]
lmb: Return -EEXIST in lmb_add_region_flags() if region already added
An attempt to add the already added LMB region using
lmb_add_region_flags() ends up in lmb_addrs_overlap() check, which
eventually leads to either returning 0 if 'flags' is LMB_NONE, or -1
otherwise. It makes it impossible for the user of this function to catch
the case when the region is already added and differentiate it from
regular errors. That in turn may lead to incorrect error handling in the
caller code, like reporting misleading errors or interrupting the normal
code path where it could be treated as the normal case. An example is
boot_fdt_reserve_region() function, which might be called twice (e.g.
during board startup in initr_lmb(), and then during 'booti' command
booting the OS), thus trying to reserve exactly the same memory regions
described in the device tree twice, which produces an error message on
second call.
Return -EEXIST error code in case when the added region exists and it's
not LMB_NONE; for LMB_NONE return 0, to conform to unit tests
(specifically test_alloc_addr() in test/lib/lmb.c) and the preferred
behavior described in commit 1d9aa4a283da ("lmb: Fix the allocation of
overlapping memory areas with !LMB_NONE"). The change of
lmb_add_region_flags() return values is described in the table below:
Rework all affected functions and their documentation. Also fix the
corresponding unit test which checks reserving the same region with the
same flags to account for the changed return value.
No functional change is intended (by this patch itself).
Fixes: 1d9aa4a283da ("lmb: Fix the allocation of overlapping memory areas with !LMB_NONE") Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Michal Simek <michal.simek@amd.com>
Peter Robinson [Fri, 11 Oct 2024 17:09:11 +0000 (18:09 +0100)]
board: rpi: Pass CMA through from firmware DT
For a lot of usecases, such as display, camera, media
the Raspberry Pi needs a lot more CMA than distros
configure as default so we should pass this parameter
through so things work as expected. Fix a spelling
mistake while we're at it.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Acked-by: Matthias Brugger <mbrugger@suse.com>
- Add support for the NXP i.MX91 EVK board.
- Improve EEPRON suport on i.MX8MP DHCOM board.
- Switch phycore_imx8mm to using environment text files and improve
environment handling.
Marek Vasut [Thu, 28 Nov 2024 04:11:19 +0000 (05:11 +0100)]
arm64: renesas: Disable AVB1 and AVB2 on R8A779G0 V4H White Hawk board
The U-Boot is currently not capable of handling ethernet-phy-ieee802.3-c45
PHYs correctly, and also does not handle MDIO bus wide reset-gpios property.
Until proper C45 PHY support lands in U-Boot, disable AVB1/AVB2 interfaces.
This only disables the two MACs with 88Q2110/88Q2112 100/1000BASE-T1 PHYs
on ethenet sub-board, the main board AVB0 ethernet is unaffected.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Paul Barker [Wed, 20 Nov 2024 09:48:29 +0000 (09:48 +0000)]
pinctrl: rzg2l: Support Ethernet TXC output enable
On the RZ/G2L SoC family, the direction of the Ethernet TXC/TX_CLK
signal is selectable to support an Ethernet PHY operating in either MII
or RGMII mode. By default, the signal is configured as an input and MII
mode is supported. The ETH_MODE register can be modified to configure
this signal as an output to support RGMII mode.
As this signal is be default an input, and can optionally be switched to
an output, it maps neatly onto an `output-enable` property in the device
tree.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Paul Barker [Wed, 20 Nov 2024 09:48:28 +0000 (09:48 +0000)]
pinctrl: rzg2l: Support 2.5V PVDD for Ethernet interfaces
The Ethenet interfaces on the Renesas RZ/G2L SoC family can operate at
multiple power supply voltages: 3.3V (default value), 2.5V and 1.8V.
rzg2l_pinconf_set() is extended to support the 2.5V setting, with a
check to ensure this is only used on Ethernet interfaces as it is not
supported on the SD & QSPI interfaces.
While we're modifying rzg2l_pinconf_set(), drop the unnecessary default
value for pwr_reg as it is set in every branch of the following if
condition.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Paul Barker [Tue, 19 Nov 2024 19:36:26 +0000 (19:36 +0000)]
clk: rzg2l: Ignore enable for core clocks
In the RZ/G2L family, core clocks are always on and can't be disabled.
However, drivers which are shared with other SoCs may call clk_enable()
or clk_enable_bulk() for a clock referenced in the device tree which
happens to be a core clock on the RZ/G2L. To avoid the need for
conditionals in these drivers, simply ignore attempts to enable a core
clock.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
board: dhelectronics: Sync env variable dh_som_serial_number with SN
The env variable "SN" is used to store the serial number on DH electronics
SoMs. New SoMs will use the variable "dh_som_serial_number". To ensure
compatibility, these env variables are synchronized. This is achieved
using callback functions.
Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> Reviewed-by: Marek Vasut <marex@denx.de>
lib: hashtable: Prevent recursive calling of callback functions
In case there are two variables which each implement env callback
that performs env_set() on the other variable, the callbacks will
call each other recursively until the stack runs out. Prevent such
a recursion from happening.
Example which triggers this behavior:
static int on_foo(...) { env_set("bar", 0); ... }
static int on_bar(...) { env_set("foo", 0); ... }
U_BOOT_ENV_CALLBACK(foo, on_foo);
U_BOOT_ENV_CALLBACK(bar, on_bar);
Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> Suggested-by: Marek Vasut <marex@denx.de>
arm64: imx8mp: Read values from M24C32-D write-lockable page on DHCOM i.MX8MP
The new i.MX8M Plus DHCOM rev.200 is populated with M24C32-D EEPROM
that contains an additional write-lockable page called ID page, which
is populated with a structure containing ethernet MAC addresses, DH
item number and DH serial number.
Because the write-lockable page is not present on rev.100 i.MX8MP DHCOM
SoM, test whether EEPROM ID page exists by setting up the i2c driver.
There may be multiple EEPROMs with an ID page on this platform, always
use the first one. The evaluation of the EEPROM ID page is done in two
steps. First, the content is read and checked. This is done to cache
the content of the EEPROM ID page. Second, the content is extracted
from the EEPROM buffer by requesting it.
For the ethernet MAC address the i.MX8M Plus DHCOM currently supports
parsing address from multiple sources in the following priority order:
Add support for parsing the content of this new EEPROM ID page and place
it between 2) and 3) on the priority list. The new entry is 2.5) On-SoM
EEPROM write-lockable page.
Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> Reviewed-by: Marek Vasut <marex@denx.de>
arm64: dts: imx8mp: Add aliases for the access to the EEPROM ID page node
The new i.MX8M Plus DHCOM rev.200 is populated with M24C32-D EEPROM
that contains an additional write-lockable page called ID page. Add
aliases eeprom0wl and eeprom1wl for the access to the EEPROM ID
page node.
Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> Reviewed-by: Marek Vasut <marex@denx.de>
projects / thirdparty / u-boot.git / log
