Age | Commit message (Collapse) | Author |
|
Jayesh Choudhary <j-choudhary@ti.com> says:
Add QOS support for DSS in TI K3 SoC to route the DSS traffic through
RT queue by setting orderID as 15:
- J722S
- AM62P
Link: https://lore.kernel.org/r/20241126070614.47136-1-j-choudhary@ti.com
|
|
Enable CONFIG_K3_QOS to set QoS registers in R5 boot stage.
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
|
|
Enable CONFIG_K3_QOS to set QoS registers in R5 boot stage.
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
|
|
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.
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
|
|
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.
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Reviewed-by: Devarsh Thakkar <devarsht@ti.com>
|
|
This reverts commit 1fdf53ace13f745fe8ad4d2d4e79eed98088d555, reversing
changes made to e5aef1bbf11412eebd4c242b46adff5301353c30.
I had missed that this caused too much size growth on rcar3_salvator-x.
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
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.
Link: https://lore.kernel.org/r/20241207172412.1124558-1-sjg@chromium.org
|
|
Add an entry for crc8, with watchdog handling.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
VBE uses a crc8 checksum to verify that the nvdata is valid, so make
sure it is available if VBE is enabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Provide options to enable the CRC8 feature in TPL and VPL builds.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
With VBE we want to use FIT in all phases of the boot. Add Kconfig
options to support this.
Disable the options for sandbox_vpl for now.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Add Kconfig symbols and update the Makefile rules so that decompression
can be used in TPL and VPL
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Add debugging of image-loading progress. Fix a stale comment in the
function comment while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
The variable 'ret' is defined twice, which is not intended. This may
have been a local merge error.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 2eefeb6d893 ("spl: Report a loader failure")
|
|
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
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
The current check looks only at SPL, but TPL or VPL might have a
different setting. Update the condition.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
The current check looks only at SPL, but TPL or VPL might have a
different setting. Update the condition.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
If a loader returns an error code it is silently ignored. Show a message
to at least provide some feedback to the user.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Add a size limit for VPL, to match those for SPL and TPL
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
The VPL phase may want to use the smaller malloc() implementation, so
add an option for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Show a bit more information when malloc() space is exhausted and
debugging is enabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Some code has crept in which ignores this parameter. Fix this and add a
little debugging.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: b1307f884a9 ("fit: Support compression for non-kernel components (e.g. FDT)")
|
|
The name of the bootdev device is not that important, particular in SPL.
Save a little code space by using a simpler name.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
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.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
This function exists but is not exported. Add a prototype so it can be
used elsewhere.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
The for() loop ends up being in the code even if the log_debug() does
nothing. Add a condition to fix this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
|
|
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>
|
|
Prepare v2025.01-rc4
|
|
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
https://gitlab.denx.de/u-boot/custodians/u-boot-imx into next
CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/23736
- 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.
|
|
|
|
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>
|
|
In rzg2l_pinconf_set(), there are no new variables defined in the case
statement for PIN_CONFIG_INPUT_ENABLE so no additional scope is needed.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
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>
|
|
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>
|
|
We can call dev_read_u32_default() instead of calling fdt_getprop() then
fdt32_to_cpu().
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
|
|
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>
|
|
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>
|
|
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>
|
|
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:
1) U-Boot environment 'ethaddr'/'eth1addr' environment variable
2) SoC OTP fuses
3) On-SoM EEPROM
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>
|
|
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>
|
|
Add i.MX91 11x11 EVK Board support.
- Four ddr scripts included w/o inline ecc feature.
- SDHC/NETWORK/I2C/UART supported
- PCA9451 supported, default nominal drive mode
- Documentation added.
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
Add the i.MX91 device tree from [1]. These files could be synced
to linux upstream after [1] merged to linux source tree.
[1]
https://lore.kernel.org/all/20241120094945.3032663-1-pengfei.li_1@nxp.com/
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
Reuse i.MX93 pinctrl driver for i.MX91, because i.MX91 follows same
design as i.MX93 in IOMUXC controller.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
iMX91 reuses iMX93 controller and PHY, but with lower speed,
so add new DDR rates for i.MX91.
Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
Add new rates to integer and frac PLL to support iMX91
Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
i.MX91 is a derived from i.MX93, and most clocks could be reused from
i.MX93. Also Update imx93-clock.h to sync with linux next.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
iMX91 is reduced part from iMX93 with part number: i.MX9131/11/01
It removed A55_1, M33, MIPI DSI, LVDS, etc.
i.MX9131:
- Support 2.4GT/s DDR and HWFFC at 1.2GT/s
i.MX9121:
- A55 at 800Mhz and DDR at 1600MTS, with low drive mode.
i.MX9111:
- Support 1.6GT/s DDR and HWFFC at 800MT/s
i.MX9101:
- Support 800Mhz ARM clock
- Support 1.6GT/s DDR and HWFFC at 800MT/s
- No parallel display, eQOS, flexcan
Updated Clock/Container/CPU and etc for i.MX91
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
According to iMX93 fuse burn plan, all 9x9 parts will have USB2,
ENET1 (FEC), LVDS1, CSI1 and DSI1 disabled. The codes missed ENET1
fuse when detecting 9x9. Although it still can detect 9x9 correctly,
we add the ENET1 fuse to the check to be more accurate.
Fixes: 58da865e27f ("imx9: add i.MX93 variants support")
Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
Include types.h header for u32, following Linux Coding Style to include
necessary headers.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|