Describe the current situation wrt the handling of USB devices on AM33xx
based boards, taking the example of a common board (the Beagle Bone
Black) and explaining how the different USB gadgets can be used.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Bootloader debug usually tends to be a bit dicey prior to DDR and
serial port getting active in the system. JTAG typically remains the
only practical debug option during the initial bringup.
OpenOCD is one of the most popular environment for providing debug
capability via a GDB compatible interface for developers to work with.
Debugging U-Boot and bootloaders on K3 platform does have a bit of
tribal knowledge that is better documented in our common platform
documentation.
Signed-off-by: Jason Kacines <j-kacines@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
This adds initial support for the Toradex Verdin AM62 Quad 1GB WB IT
V1.0A module and subsequent V1.1 launch configuration SKUs. They are
strapped to boot from their on-module eMMC. U-Boot supports booting
from the on-module eMMC only, DFU support is disabled for now due to
missing AM62x USB support.
The device trees were taken straight from Linux v6.5-rc1.
Boot sequence is:
SYSFW ---> R5 SPL (both in tiboot3.bin) ---> ATF (TF-A) ---> OP-TEE
---> A53 SPL (part of tispl.bin) ---> U-boot proper (u-boot.img)
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Nishanth Menon <nm@ti.com>
Add Licensing to svg images to clarify the terms.
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Introduce common variables to define a generic build instruction that is
then used in specific board specific description.
Labels are introduced in the evm.rst files to be then reused in variant
board documentation as well.
While at this, drop using ARCH=arm when building u-boot sources. This
practice has been discouraged for some time and can potentially create
problems with Kconfig rules related to aarch64. It's best to avoid
this approach.
Signed-off-by: Nishanth Menon <nm@ti.com>
Update the bootflow svg diagram instead of the ascii version
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Update the bootflow svg diagram instead of the ascii version
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Update the bootflow svg diagram and reuse across the platforms as they
are common.
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
We have duplication of sources which makes it hard to sustain across the
board, but at the same time, we'd like to ensure readers get specific
information without having to cross refer to different documentation to
get piecemeal information that they need to put together.
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Now that we are using binman in all cases on these platforms, reword
things to be clearer that for filesystem booting we need to use a
specific name for each component.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Having saved environments usually causes inconsistencies while in
development workflow. The saved environments conflict with the
default ones that U-boot should be updating during development
but that doesn't happen and the saved environments need to be
reset during bootups to test the changes causing extra debugs.
Remove the saved environments as a default. Environments can always
be re-enabled locally if one does like them or needs them for
some production environment. Optionally, Uenv.txt can also be used on
some of the boot media.
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
Earlier documentation specified builds for generating bootloader images
using an external TI repository k3-image-gen and core-secdev-k3. Modify
this to using the binman flow so that user understands how to build the
final boot images.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
To understand usage of DDR in A53 SPL stage, add a table showing region
and space used by major components of SPL.
Signed-off-by: Nikhil M Jain <n-jain1@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
This patch adds documentation for j7200.
TRM link
https://www.ti.com/lit/pdf/spruiu1
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
In non-combined boot flow for K3, all the firewalls are locked by default
until sysfw comes up. Rom configures some of the firewall for its usage
along with the SRAM for R5 but the PSRAM region is still locked.
The K3 MCU Scratchpad for j721e was set to a PSRAM region triggering the
firewall exception before sysfw came up. The exception started happening
after adding multi dtb support that accesses the scratchpad for reading
EEPROM contents.
The commit changes R5 MCU scratchpad for j721e to an SRAM region.
Old Map:
┌─────────────────────────────────────┐ 0x41c00000
│ SPL │
├─────────────────────────────────────┤ 0x41c40000 (approx)
│ STACK │
├─────────────────────────────────────┤ 0x41c85b20
│ Global data │
│ sizeof(struct global_data) = 0xd8 │
├─────────────────────────────────────┤ gd->malloc_base = 0x41c85bfc
│ HEAP │
│ CONFIG_SYS_MALLOC_F_LEN = 0x70000 │
├─────────────────────────────────────┤ CONFIG_SPL_BSS_START_ADDR
│ SPL BSS │ (0x41cf5bfc)
│ CONFIG_SPL_BSS_MAX_SIZE = 0xA000 │
└─────────────────────────────────────┘ CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX
(0x41cffbfc)
New Map:
┌─────────────────────────────────────┐ 0x41c00000
│ SPL │
├─────────────────────────────────────┤ 0x41c40000 (approx)
│ EMPTY │
├─────────────────────────────────────┤ 0x41c81920
│ STACK │
│ SPL_SIZE_LIMIT_PROVIDE_STACK=0x4000 │
├─────────────────────────────────────┤ 0x41c85920
│ Global data │
│ sizeof(struct global_data) = 0xd8 │
├─────────────────────────────────────┤ gd->malloc_base = 0x41c859f0
│ HEAP │
│ CONFIG_SYS_MALLOC_F_LEN = 0x70000 │
├─────────────────────────────────────┤ CONFIG_SPL_BSS_START_ADDR
│ SPL BSS │ (0x41cf59f0)
│ CONFIG_SPL_BSS_MAX_SIZE = 0xA000 │
├─────────────────────────────────────┤ 0x41cff9fc
│ NEW MCU SCRATCHPAD │
│ SYS_K3_MCU_SCRATCHPAD_SIZE = 0x200 │
└─────────────────────────────────────┘ CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX
(0x41cffbfc)
Fixes: ab977c8b91 ("configs: j721s2_evm_r5: Enable support for building multiple dtbs into FIT")
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
[n-francis@ti.com: SRAM allocation addressing diagram]
Signed-off-by: Neha Francis <n-francis@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Kamlesh Gurudasani <kamlesh@ti.com>
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>
Texas Instrument's entire K3 generation of SoCs use much of the same
frameworks and boot flow, especially at the uboot level. Though there
are small differences introduced as each new K3 based SoC is developed
and as the K3 generation matures that will also need to be documented.
Rather than copying the same documentation, with the small differences
applicable to that specific SoC to a new page, introduce a new K3
page that can describe the general boot flow and design decisions for
the entire K3 generation of chips, leaving the specifics for that
particular SoC to a unique sub-page below this one.
Signed-off-by: Bryan Brattlof <bb@ti.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Texas Instruments produces quite a lot of SoCs based upon a common
architecture 'generation'. (eg: OMAP, K3) TI's existing documentation
layout makes noticing this generation jump rather difficult.
To make navigation easier, split the existing documentation into
individual SoC families so we may begin grouping them according to their
generational (eg: OMAP, K3) families.
Signed-off-by: Bryan Brattlof <bb@ti.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The rest of the unmigrated CONFIG symbols in the CONFIG_SYS_NAND
namespace do not easily transition to Kconfig. In many cases they likely
should come from the device tree instead. Move these out of CONFIG
namespace and in to CFG namespace.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
* BASH code should be labeled as such.
* Code blocks should be indented by 4 spaces.
Fix these here.
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
- At this point there are a large number of Beaglebone boards, refer to
them as a family rather than a growing list.
- Reword customization as we're largely Kconfig-oriented now.
- Remove the NOR section as the relevant defconfigs have long been
removed and the general support was not updated.
Signed-off-by: Tom Rini <trini@konsulko.com>
Add documentation for loading firmwares to be used by remote cores in
the system including the environment variables that has to be set to
load the firmwares.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210721155849.20994-21-kishon@ti.com
Move j721e document from board/ti/j721e/README to
doc/board/ti/j721e_evm.rst after converting it to RST format.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210721155849.20994-20-kishon@ti.com
