Enable USB host as well as USB gadget and DFU support for a53; For the
r5 due to the smaller available size create a new config just for
DFU support
Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
Enable both usb0 as a peripheral for use with DFU
Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
Add glue code for TI AM62 to the dwc3 driver; Most code adopted from
TI vendor u-boot code.
Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
sdhci0 on the k3-am625-sk is the emmc, enable this in SPL as well to
allow booting from that media.
Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
Update the am62 and am625 device-trees from linux v6.3-rc5 This needed the following
tweaks to the u-boot specific dtsi as well:
- Switch tick-timer to the main_timer as it's now defined in the main dtsi
- Add mdio pins to the cpsw3g pinctrl. It moved to a subnode in the
linux dtsi that u-boot doesn't use/support
Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
Timer0 is used by u-boot as the tick timer; Add it to the soc devices
list so it can be enabled via the k3 power controller.
Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
The TI AM654 timer is compatible with the omap-timer implementation, so
add it to the id list
Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
commit 211a06687649d33f9d56498e6aaea13286e4a34f upstream.
Add the size of regs property to the glue structure to correctly
specify the register region to map.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Reviewed-by: Marek Vasut <marex@denx.de>
commit ef2313b8a26e83c92a14b43b3b3bb1c7af017d98 upstream.
In order to allow external SoC-dependent glue drivers to use dwc3-generic
functions, push the glue structures and export the functions to a header
file.
The exported structures and functions are:
- struct dwc3_glue_data
- struct dwc3_glue_ops
- dwc3_glue_bind()
- dwc3_glue_probe()
- dwc3_glue_remove()
The SoC-dependent glue drivers can only define their own wrapper driver
and specify these functions. The drivers can also add their own compatible
strings and configure functions.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Reviewed-by: Marek Vasut <marex@denx.de>
commit 7c71c684ce697dcb79efb7f027d820a6ab82228b upstream.
Same as the reset cotnrol, should add a clock initialization in child DT
node, if the glue node doesn't have any clocks.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Reviewed-by: Marek Vasut <marex@denx.de>
commit f7b7c721332c2e262035d306296d53c2511763a0 upstream.
The most of devicetree has the following USB node structure.
The controller node is placed as a child node of the glue node.
Current dwc3-generic driver works on this premise.
glue {
/* glue node */
usb {
/* controller node */
};
};
However, UniPhier original devicetree has the following USB node structure.
The controller node is separately placed from the glue node.
usb {
/* controller node */
};
glue {
/* glue node */
};
In dwc_glue_bind(), this patch provides .glue_get_ctrl_dev() callback to
get such a controller node and binds the driver related to the node.
If this callback isn't defined, dwc_glue_bind() looks for the controller
nodes from the child nodes, as before.
Suggested-by: Marek Vasut <marex@denx.de>
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Reviewed-by: Marek Vasut <marex@denx.de>
commit c6583354b7c1aaa9608b2f92221608e42c21f1dd upstream.
There are currently four disparate placement possibilities of DWC3
reference clock phandle in SoC DTs:
- in top level glue node, with generic subnode without clock (ZynqMP)
- in top level generic node, with no subnode (i.MX8MQ)
- in generic subnode, with other clock in top level node (i.MX8MP)
- in both top level node and generic subnode (Rockchip)
Cover all the possibilities here by looking into both nodes, start
with the top level node as that seems to be used in majority of DTs
to reference the clock.
Signed-off-by: Marek Vasut <marex@denx.de>
Acked-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
There are 4 instances of SERDES modules, with each instance supporting 4
lanes.
Signed-off-by: Matthew Ranostay <mranostay@ti.com>
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Introduce the base dts files needed for u-boot or to augment the linux
dtbs for use in the u-boot-spl and u-boot binaries.
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Introduce the basic j784s4 SoC dtbs from the linux kernel along with
the new j784s4 specific pinmux definitions that we will use to generate
the dtbs for the u-boot-spl and u-boot binaries.
The dtbs are taken from v6.3 kernel repository.
Signed-off-by: Apurva Nandan <a-nandan@ti.com>
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Move to using .env file for setting up environment variables for am64x.
Signed-off-by: Nikhil M Jain <n-jain1@ti.com>
Reviewed-By: Devarsh Thakkar <devarsht@ti.com>
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Test that:
- sandbox shows a warning when an unmigrated DT is used
- sandbox fails to run when migration is turned off
- sandbox_spl fails to build when migration is turned off
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
This is useful when we need to control a particular environment variable.
Add a way to handle this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
These should not be used anymore. Add a check to ensure they don't creek
back into U-Boot. Use bootph-... instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Help ensure that these don't creep into development by adding a check in
checkpatch for them.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Now that Linux has accepted these tags, update the dtoc tool to use them.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Now that Linux has accepted these tags, move U-Boot over to use them.
Tidy up the comments and formatting, making sure that VPL is mentioned
too.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Now that Linux has accepted these tags, move U-Boot over to use them.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Update various build and test components to use the new schema.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Now that Linux has accepted these tags, move the device tree files in
U-Boot over to use them.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Add a CONFIG option to deal with this automatically, printing a warning
when U-Boot starts up. This can be useful if the device tree comes from
another project.
We will maintain this through the 2023.07 release, providing 6 months
for people to notice.
Version 4:
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
U-Boot has some particular challenges with device tree and devices:
- U-Boot has multiple build phases, such as a Secondary Program Loader
(SPL) phase which typically runs in a pre-SDRAM environment where code
and data space are limited. In particular, there may not be enough
space for the full device tree blob. U-Boot uses various automated
techniques to reduce the size from perhaps 40KB to 3KB. It is not
always possible to handle these tags entirely at build time, since
U-Boot proper must have the full device tree, even though we do not
want it to process all nodes until after relocation.
- Some U-Boot phases needs to run before the clocks are properly set up,
where the CPU may be running very slowly. Therefore it is important to
bind only those devices which are actually needed in that phase
- U-Boot uses lazy initialisation for its devices, with 'bind' and
'probe' being separate steps. Even if a device is bound, it is not
actually probed until it is used. This is necessary to keep the boot
time reasonable, e.g. to under a second
The phases of U-Boot in order are: TPL, VPL, SPL, U-Boot (first
pre-relocation, then post-relocation). ALl but the last two are optional.
For the above reasons, U-Boot only includes the full device tree in the
final 'U-Boot proper' build. Even then, before relocation U-Boot only
processes nodes which are marked as being needed.
For this to work, U-Boot's driver model[1] provides a way to mark device
tree nodes as applicable for a particular phase. This works by adding a
tag to the node, e.g.:
cru: clock-controller@ff760000 {
bootph-all;
compatible = "rockchip,rk3399-cru";
reg = <0x0 0xff760000 0x0 0x1000>;
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
...
};
Here the "bootph-all" tag indicates that the node must be present in all
phases, since the clock driver is required.
There has been discussion over the years about whether this could be done
in a property instead, e.g.
options {
bootph-all = <&cru> <&gpio_a> ...;
...
};
Some problems with this:
- we need to be able to merge several such tags from different .dtsi files
since many boards have their own specific requirements
- it is hard to find and cross-reference the affected nodes
- it is more error-prone
- it requires significant tool rework in U-Boot, including fdtgrep and
the build system
- is harder (slower, more code) to process since it involves scanning
another node/property to find out what to do with a particular node
- we don't want to add phandle arguments to the above since we are
referring, e.g., to the clock device as a whole, not a paricular clock
- the of-platdata feature[2], which converts device tree to C for even
more constrained environments, would need to become aware of the
/options node
There is also the question about whether this needs to be U-Boot-specific,
or whether the tags could be generic. From what I can tell, U-Boot is the
only bootloader which seriously attempts to use a runtime device tree in
all cases. For this version, an attempt is made to name the phases in a
generic manner.
It should also be noted that the approach provided here has stood the test
of time, used in U-Boot for 8 years so far.
So add the schema for this. This will allow a major class of schema
exceptions to be dropped from the U-Boot source tree.
This has been applied upstream[3]
[1] https://u-boot.readthedocs.io/en/latest/develop/driver-model/index.html
[2] https://u-boot.readthedocs.io/en/latest/develop/driver-model/of-plat.html
[3] https://github.com/devicetree-org/dt-schema/commit/63bd847
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
commit 354c05f265eb42ef90e5411ddad684f752d0587b upstream.
List some common boot modes and their corresponding switch
settings for AM62 SK.
Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Build tispl.bin as well for secure device builds. Note this will be
redundant post migration to binman
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The AM64x SR2.0 SK board uses "AM64B-SKEVM" as the EEPROM identifier.
This board is similar to the AM64x SKEVM except that it has a new
PMIC that will be enabled in the future and consequently could use a
different device tree file in the future.
For now we treat the board same as an AM64x SK.
Signed-off-by: Judith Mendez <jm@ti.com>
Acked-by: Andrew Davis <afd@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Errata doc: https://www.ti.com/lit/pdf/sprz457
Errata ID i2331 CPSW: Device lockup when reading CPSW registers
Details: A device lockup can occur during the second read of any CPSW
subsystem register after any MAIN domain power on reset (POR). A MAIN
domain POR occurs using the hardware MCU_PORz signal, or via software
using CTRLMMR_RST_CTRL.SW_MAIN_POR or CTRLMMR_MCU_RST_CTRL.SW_MAIN_POR.
After these resets, the processor and internal bus structures may get
into a state which is only recoverable with full device reset using
MCU_PORz.
Due to this errata, Ethernet boot should not be used on this device.
Workaround(s): To avoid the lockup, a warm reset should be issued after
a MAIN domain POR and before any access to the CPSW registers. The warm
reset realigns internal clocks and prevents the lockup from happening.
Workaround above errata by calling do_reset() in case of cold boot in
order to trigger warm reset. This needs enabling SYSRESET driver in R5
SPL to enable TI SCI reset driver.
Signed-off-by: Nitin Yadav <n-yadav@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Enable the CONFIG_TI_SECURE_DEVICE by default
Non-HS devices will continue to boot due to runtime device type detection.
TI's security enforcing SoCs will authenticate each binary it loads by
comparing it's signature with keys etched into the SoC during the boot
up process. The am62x family of SoCs by default will have some level of
security enforcement checking. To keep things as simple as possible,
enable the CONFIG_TI_SECURE_DEVICE options by default so all levels of
secure SoCs will work out of the box
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Signed-off-by: Kamlesh Gurudasani <kamlesh@ti.com>
Signed-off-by: Bryan Brattlof <bb@ti.com>
commit f4449397551a82f0c1d9714d648f1efb90d56962 upstream.
mkbootimg tool is part of the Android project and it is
used to pack Android boot images such as boot image
and vendor_boot image.
Use the following command to run mkbootimg:
$ python3 -m mkbootimg
Add mkbootimg to the docker file
Signed-off-by: Safae Ouajih <souajih@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Andrew Davis
Sjoerd Simons
Kunihiko Hayashi
Marek Vasut
Hari Nagalla
Nikhil M Jain
Simon Glass
Judith Mendez
Vignesh Raghavendra
Nitin Yadav
Praneeth Bajjuri
Safae Ouajih