In the x86emuOp_jump_call_near_IMM() function the target address is
printed incorrectly when jumping backwards. For example instead of
"jmp 0xe8bc" the string "jmp ffffe8bc" is printed. That's because
of the following macro:
DECODE_PRINTF2("%04x\n", ip);
while it should be
DECODE_PRINTF2("%04x\n", (u16)ip);
Signed-off-by: Yuri Zaporozhets <yuriz@qrv-systems.net>
In the x86emuOp_call_near_IMM() function the address of CALL is
printed incorrectly when jumping backwards. For example, the correct
disassemble of the bytes below would be:
0000E8DE E8DBFF call 0xe8bc
(verified by ndisasm). But instead the address is printed as "ffffe8bc".
That's because of the following macro:
DECODE_PRINTF2("%04x\n", ip);
while it should be
DECODE_PRINTF2("%04x\n", (u16)ip);
Signed-off-by: Yuri Zaporozhets <yuriz@qrv-systems.net>
When DEBUG_DECODE_F is enabled in bios_emulator, the printing of
SET{O,NO,B,NB,Z,NZ,BE,NBE,S,NS,P,TP,L,NL,LE,NLE} instructions
is not followed by newline and is, therefore, immediately followed
by the printed address of a new instruction. This garbles the output
and makes it very difficult to read.
This patch adds missing DECODE_PRINTF("\n") calls to print newlines.
Signed-off-by: Yuri Zaporozhets <yuriz@qrv-systems.net>
When DEBUG_DECODE_F is enabled in bios_emulator, the printing of BSF
instructions is garbled because the '\n' symbol is used instead of
the correct '\t'. Fix that.
Signed-off-by: Yuri Zaporozhets <yuriz@qrv-systems.net>
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.
Test logs:
1) j721e-idk-gw hyperflash boot test: https://gist.github.com/anuragdutta731/50aae6fec707a3ffad6d985de6757fe4
2) j7200-evm hyperflash boot test: https://gist.github.com/anuragdutta731/c3a4d60f8bfd9c425d6c44b36eb7322b
Link: https://lore.kernel.org/r/20241129113136.383277-1-a-dutta@ti.com
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.
Signed-off-by: Anurag Dutta <a-dutta@ti.com>
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.
Fixes: cf1d6867f7 ("board: ti: j7200: Introduce support for j7200 build targets")
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Signed-off-by: Anurag Dutta <a-dutta@ti.com>
Add 32-bit address overrides for Hyper Bus Memory Controller
for Hyperflash to be functional in R5 SPL.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Signed-off-by: Anurag Dutta <a-dutta@ti.com>
Add 32-bit address overrides for Hyper Bus Memory Controller
for Hyperflash to be functional in R5 SPL.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Signed-off-by: Anurag Dutta <a-dutta@ti.com>
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.
Signed-off-by: Anurag Dutta <a-dutta@ti.com>
Instead of bloating the defconfig with CONFIG_CMD_*, move J7 devices to
start using TI_COMMON_CMD_OPTIONS.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Add CMD_NFS to list of configs implied by CONFIG_TI_COMMON_CMD_OPTIONS.
This allows network booting via the NFS protocol from the U-Boot prompt.
Fixes: 10de125707 ("disable NFS support by default")
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
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.
Boot logs link :
https://gist.github.com/GOKU-THUG/8b90117c963e5da5c1b6caeee427c82c
Link: https://lore.kernel.org/r/20241126105131.43359-1-g-praveen@ti.com
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>
Increase scope of ops functions and do some clean up for usage in device
-specific UART drivers.
Remove the static functionality of ops functions and migrate certain macros
to header file for usage in device-specific drivers.
Signed-off-by: Gokul Praveen <g-praveen@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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
Link: https://lore.kernel.org/r/20241118231606.3161665-1-ggiordano@phytec.com
[trini: Fix warning in board/phytec/common/k3/board.c when
CONFIG_EFI_HAVE_CAPSULE_SUPPORT is not enabled]
Signed-off-by: Tom Rini <trini@konsulko.com>
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 <w.egorov@phytec.de> says:
This implements capsule updates for all our K3 SoMs for
eMMC, OSPI NOR and uSD cards.
We can use capsule updates to update the bootloader on all our
supported flash devices.
Link: https://lore.kernel.org/r/20241127121736.1525948-1-w.egorov@phytec.de
Enable raw & on disk capsule updates and provide configs required
for updating MTD devices. Also resync after savedefconfig.
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
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
Link: https://lore.kernel.org/r/20241126120322.1760862-1-s-vadapalli@ti.com
Include the TI K3 DFU environment to support DFU Boot and DFU Flash.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Roger Quadros <rogerq@kernel.org>
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>
Enables ESM configs for j721s2 and disables them for AM68 as AM68
includes J721s2 configs by default.
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
Initialize the 3 instances of SOC ESM & PMIC ESM.
This is needed for watchdog functionality.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Udit Kumar <u-kumar1@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 1fdf53ace1, reversing
changes made to e5aef1bbf1.
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
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>
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>
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")
